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Abstract 

This paper presents an overview of NASA Langley’s research program in formal methods. 
The major goal of this work is to bring formal methods technology to a sufficiently mature 
level for use by the United States aerospace industry. Towards this goal, work is under- 
way to design and formally verify a fault-tolerant computing platform suitable for advanced 
flight control applications. Also several direct technology transfer efforts have been initiated 
that apply formal methods to critical subsystems of real aerospace computer systems. The 
research team consists of six NASA civil servants and contractors from Boeing Military Air- 
craft Company, Computational Logic Inc., Odyssey Research Associates, SRI International, 
University of California at Davis, and Vigyan Inc. 


Motivation 

NASA Langley Research Center has been developing techniques for the design and validation 
of flight critical systems for over two decad es. A lthough much progress has been made in 
developing methods which can accommodate physical failures, the design flaw remains a 
serious problem [2, 3, 4, 5, 6, 7, 8]. 

A recent report by the National Center For Advanced Technologies has identified Prov- 
ably Correct System Specification” and “Verification Formalism For Error-Free Specifica- 
tion” as key areas of research for future avionics software and ultrareliable electronics systems 
[9]. Aerospace engineers attending the NASA-LaRC Flight Critical Digital Systems Tech- 
nology Workshop [10] listed techniques for the validation of concurrent and fault- tolerant 
computer systems high on the list of research priorities for NASA. 

•This is an updated version of the a paper entitled “NASA Langley’s Research Program in Formal 

Methods” presented at COMPASS 91 [1]. , ... 

‘A technical council funded by the Aerospace Industries Association of America (AIA) that represents the 
major U.S. aerospace companies engaged in the research, development and manufacture of aircraft, missiles 
and space systems and related propulsion, guidance, control and other equipment. 
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A further motivation for the use of formal methods is the practical limitations of life- 
testing methods to quantify reliability in the ultrareliable domain. Unfortunately, the quan- 
tification of reliability in the presence of design faults has been found to be infeasible whether 
applied to hardware or software (standard or fault-tolerant) [11]. Therefore the use of non- 
statistical method is necessary. 


Formal Methods 

Formal methods are the applied mathematics of computer systems engineering. There are 
many different types of formal methods with various degrees of rigor. The following is a 
useful (first-order) taxonomy of the degrees of rigor in formal methods: 

Level-1: Formal specification of all or part of the system. 

Level-2: Formal specification at two or more levels of abstraction and paper and 
pencil proofs that the detailed specification implies the more abstract spec- 
ification. 

Level-8: Formal proofs checked by a mechanical theorem prover. 

Level 1 represents the use of mathematical logic or a specification language that has a 
formal semantics to specify the system. This can be done at several levels of abstraction. 
For example, one level might enumerate the required abstract properties of the system, 
while another level describes an implementation which is algorithmic in style. Level 2 formal 
methods goes beyond level 1 by developing pencil-and-paper proofs that the more concrete 
levels logically imply the more abstract-property oriented levels. Level 3 is the most rigorous 
application of formal methods. Here one uses a semi-automatic theorem prover to make ‘Safe 
that all of the proofs are valid. The Level 3 process of convincing a mechanical prover is 
really a process of developing an argument for an ultimate skeptic who must be shown every 
detail. 

It is also important to realize that formal methods is not an all-or-nothing approach. 
The application of formal methods to the most critical portions of a system is a pragmatic 
and useful strategy. Although a complete formal verification of a large complex system is 
impractical at this time, a great increase in confidence in the system can be obtained by the 
use of formal methods at key locations in the system. 


Research Team 

The Langley formal methods program involves both in-house researchers and industrial/ academic 
researchers working under contract to NASA Langley. Currently the in-house team consists 
of six civil servants and one in-house contractor (Vigyan Inc.). NASA Langley has awarded 
three contracts specifically devoted to formal methods (from the competitive NASA RFP 
1-22-9130.0238). The selected contractors were SRI International, Computational Logic 
Inc., and Odyssey Research Associates. The three contracts are five-year, task assignment 
contracts with total spending authority at approximately S2.5M per contract. Another 
task-assignment contract with Boeing Military Aircraft Company (BMAC) is being used to 
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explore formal methods as well. Through this contract BMAC is funding research at the 
University of California at Davis and California Polytechnic State University to assist them 
in the use of formal methods in aerospace applications. 

NASA Langley’s Research Strategy 

The basic strategy of the research effort is to apply existing formal methods to challenging 
aerospace designs. This strategy leverages the huge investment of DARPA and National 
Security Agency in development of tools and concentrates on the problems specific to the 
aerospace problem domain. We have sought to build a strong inhouse research program 
as well as use contracts with the leading U.S. formal methods research teams (i.e. SRI, 
CLI, ORA) and aerospace industrial teams (BMAC, Draper Labs). In the short term we 
are seeking to apply formal methods to critical subsystems. In the medium term we are 
designing and verifying a reliable computing platform. Only in the long-term will we seek to 
make production-quality verification tools that are easily used by design engineers without 
overly specialized, detailed knowledge of formal methods. 

The design of a digital flight control system involves two dissimilar activities: 

1. design and implementation of control laws 

2. design of the fault-tolerant computing platform which executes the control laws 

Although these design activities are intimately connected, they require uniquely different 
skills. The first activity requires knowledge of feedback control theory and aerodynamics as 
well as numerical methods. The second activity requires knowledge of fault-tolerance theory 
and computer architecture. Although both activities are essential, we are concentrating at 
this time on the second activity. To facilitate the development and demonstration of tools 
and techniques to support the second activity, a reliable computing platform (RCP) is being 
developed. Also, several tasks are underway to facilitate the transfer of formal methods 
technology to aerospace industry. 

The Reliable Computing Platform 

The Reliable Computing Platform (RCP) dispatches the control-law application tasks and 
executes them on redundant processors. The reliable computing platform performs the 
necessary fault-tolerant functions and provides an interface to the network of sensors and 

actuators. 

The RCP consists of both hardware and software components. A real-time operating sys- 
tem provides the applications software developer with a reliable mechanism for dispatching 
periodic tasks on a fault-tolerant computing base that appears to him as a single ultra- 
reliable processor. Traditionally, an operating system has been implemented as an executive 
(or main program) that invokes subroutines implementing the application tasks. Commu- 
nication between the tasks has been accomplished by use of shared memory. This strategy 
is effective for systems with nominal reliability requirements where a simplex processor can 
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be used. For ultra-reliable systems, the additional responsibility of providing fault tolerance 
makes this approach untenable. 

For these reasons, the operating system and replicated computer architecture must be 
designed together so they mutually support the goals of the RCP. A multi-level hierarchical 
specification of the RCP is shown in figure 1. 



Figure 1: Hierarchical Specification of the Reliable Computing Platform (RCP) 

The top level of the hierarchy describes the operating system as a function that sequen- 
tially invokes application tasks. This view of the operating system will be referred to as the 
u niprocessor speci fication (US), which is formalized as a state transition system and forms 
the basis of the specification for the RCP. Fault tolerance is achieved by voting results com- 
puted by the replicated processors operating on the same inputs. Interactive consistency 
checks on sensor inputs and voting of actuator outputs require synchronization of the repli- 
cated processors. The second level in the hierarchy (RS) describes the operating system as 
a synchronous system where each replicated processor executes the same application tasks. 
The existence of a glo bal time base, an interactive consistency mechanism and a reliable 
voting mechanism are assumed at this level. Level 3 of the hierarchy breaks a frame into 
four sequential phases. This allows a more explicit modeling of interprocessor communica- 
tion and the time phasing of computation, communication, and voting. At the fourth level, 
the assumptions of the synchronous model must be discharged. Rushby and von Henke [12] 
report on the formal verification of Lamport and Melliar-Smith’s [13] interactive-convergence 
clock synchronization algorithm. This algorithm can serve as a foundation for the implemen- 
tation of the replicated system by bounding the amount of asynchrony in the system so that 
it can duplicate the functionality of the DS model. Dedicated hardware implementations of 
the clock synchronization function are a long-term goal. The LE model is currently under 
development. This model describes the actions on each local processor delineating how each 
processor schedules tasks, votes results and rewrites its own local memory with voted val- 
ues. Of primary importance in this specification is the utilization of a memory management 
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unit by the local executive in order to prevent the overwriting of incorrect memory loca- 
tions while recovering from the effects of a transient fault. There will probably be another 
level of specification introduced before the final implementation in hardware and software is 
reached. The research activity will culminate in a detailed design and prototype implemen- 
tation. Figure 2 depicts the generic hardware architecture assumed for implementing the 
replicated system. Single-source sensor inputs are distributed by special purpose hardware 
executing a Byzantine agreement algorithm. Replicated actuator outputs are all delivered 
in parallel to the actuators, where force-sum voting occurs. Interprocessor communication 
links allow replicated processors to exchange and vote on the results of task computations. 
As previously suggested, clock synchronization hardware may be added to the architecture 
as well. 

The hardware architecture is a classic N-modular redundant (NMR) system with a small 
number N of processors. Single-source sensor inputs are distributed by special purpose 
hardware executing a Byzantine agreement algorithm. Replicated actuator outputs are all 
delivered in parallel to the actuators, where force-sum voting occurs. Interprocessor com- 
munication links allow replicated processors to exchange and vote on the results of task 
computations. This is illustrated in figure 2. 
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Figure 2: Generic hardware architecture. 


The Division of Labor 

The in-house team at NASA has been orchestrating the effort to apply formal methods to 
the RCP. The design problem has been decomposed into several separate activities, some of 
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which are being investigated by contractual teams and others by the in-house team. The 
efforts are roughly divided as follows: 


In-house: 

SRI: 

CLI: 

ORA: 

BMAC: 


system architecture, clock synchronization 
Clock synchronization, fault- tolerance 
Byzantine Agreement Circuits, clock synchronization 
Byzantine Agreement Circuits, applications 
Hardware Verification, formal requirements analysis 


NASA In-house Work 

The in-house team has concentrated on the system architecture for the RCP. The top two 
levels of the RCP were originally formally specified in standard mathematical notation and 
connected via mathematical (i.e. level 2 formal methods) proof[14, 15]. Under the assump- 
tion that a majority of processors are working in each frame, the proof establishes that the 
replicated system computes the same results as a single processor system not subject to fail- 
ures. Sufficient conditions were developed that guarantee that the replicated system recovers 
from transient faults within a bounded amount of time. SRI subsequently generalized the 
models and constructed a mechanical proof in Ehdm [16]. Next, the NASA inhouse team 
developed the third and fourth level models. The top two levels and the two new models 
were then specified in Ehdm and all of the proofs were done mechanically using the Ehdm 

5.2 prover [17, 18] „ . 

Inhouse work is underway to design and implement a fault-tolerant clock synchronization 
circuit capable of recovery from transient faults [19, 20]. The circuit is being implemented 
using programmable logic devices (PLDs) and FOXI fiber optic communications chips [21]. 


Contractual Efforts 

SRI International 

The redundancy management strategies of virtually all fault-tolerant systems depend upon 
some form of voting which in turn depends upon synchronization. Although in many systems 
the clock synchronization function has not been decoupled from the applications (e.g. the 
redundant versions of the applications synchronize by messages), research and experience 
have led us to believe that solving the synchronization problem independently from the ap- 
plications design can provide significant simplification of the system [22, 23]. The operating 
system is built on top of this clock-synchronization foundation. Of course, the correctness 
of this foundation is essential. Thus, the clock synchronization algorithm and its implemen- 
tation are prime candidates for formal methods. The verification strategy shown in figure 3 
is being explored. The top-level in the hierarchy is an abstract property of the form: 

V non-faulty p, q : | C p (t) — (7,(t)| < 6 

where S is the maximum clock skew guaranteed by the algorithm as long as a sufficient 
number of clocks (and the processors they are attached to) are working. The function C p (t) 
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Figure 3: Hierarchical Verification of Clock Synchronization 

gives the value of clock p at real time t. The middle level in the hierarchy is a mathematical 
definition of the synchronization algorithm. The bottom level is a detailed digital design of 
a circuit that implements the algorithm. The bottom level is sufficiently detailed to make 
translation into silicon straight forward. 

The verification process involves two important steps: (1) verification that the algorithm 
satisfies the maximum skew property and (2) verification that the digital circuitry correctly 
implements the algorithm. The first step has already been completed by SRI International, 
The first such proof was accomplished during the design and verification of SIFT [13]. The 
proof was done by hand in the style of most journal proofs. More recently this proof step 
has been mechanically verified using the Ehdm theorem prover [12]. In addition, SRI has 
mechanically verified Schneider’s clock synchronization paradigm [24] using Ehdm[25]. A 
further generalization was found at NASA Langley [20] 2 . The design of a digital circuit to 
distribute clock values in support of fault-tolerant synchronization has been completed by 
SRI International and is currently being formally verified. 3 

SRI is currently writing a chapter for the FAA Digital Systems Validation Handbook 
Volume III on formal methods[26]. The handbook provides detailed information about digital 
system design and validation and is used by the FAA certifiers. 


Computational Logic Inc. 

Fault-tolerant systems, although internally redundant, must deal with single-source informa- 
tion from the external world. For example 1 a flight control system is built around the notion 
of feedback from physical sensors such as accelerometers, position sensors, pressure sensors, 
etc. Although these can be replicated (and they usually are), the replicates do not produce 
identical results. In order to use bit-by-bit majority voting all of the computational repli- 
cates must operate on identical input data. Thus, the sensor values (the complete redundant 
suite) must be distributed to each processor in a manner which guarantees that all working 
processors receive exactly the same value even in the presence of some faulty processors. 
This is the classic Byzantine Generals problem [27]. CLI is investigating the formal verifica- 

3 The bounded delay assumption was shown to follow from the other assumptions of the theory. ^ 
3 Unlike the NASA inhouse circuit, the SRI intent is that the convergence algorithm be implemented in 

software. 
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tion of such algorithms and their implementation. They have formally verified the original 
Marshall, Shostak, and Lamport version of this algorithm using the Boyer Moore theorem 
prover [28]. They have also implemented this algorithm down to the register-transfer level 
and demonstrated that it implements the mathematical algorithm [29] and then subsequently 
verified the design down to a hardware description language (HDL) developed at CLI [30]. 

CLI has reproduced the SRI verification of the interactive convergence algorithm using the 
Boyer-Moore theorem prover [31]. CLI has also developed a formal model of asynchronous 
communication and demonstrated its utility by formally verifying a widely used protocol for 
asynchronous communication called the bi-phase mark protocol, also known as “Bi-$-M,” 
“FM” or “single density” [32]. It is one of several protocols implemented by microcontrollers 
such as the Intel 82530 and is used in the Intel 82C501AD Ethernet Serial Interface. 


Odyssey Research Associates 

ORA has also been investigating the formal verification of Byzantine Generals algorithms. 
They have focused on the practical implementation of a Byzantine-resilient communications 
mechanism between Mini-Cayuga micro-processors [33, 34, 35]. The Mini-Cayuga is a small 
but formally verified microprocessor developed by ORA. It is a research prototype and 
has not been fabricated. The communications circuitry would serve as a foundation for a 
fault-tolerant architecture. It was designed assuming that the underlying processors were 
synchronized (say by a clock synchronization circuit). The issues involved with connecting- 
the Byzantine communications circuit with a clock synchronization circuit and verifying the 
combination has not yet been explored. 

Another task that has been started with ORA is to apply their Ada verification tools to 
aerospace applications. This effort consists of two subtasks. The first subtask is to verify 
some utility routines obtained from the NASA Goddard Space Flight Center and the NASA- 
Lewis Research Center using their Ada Verification Tool named Penelope [36]. This subtask 
was accomplished in two steps: (1) a formal specification of the routines and (2) formal 
verification of the routines. Both steps uncovered errors in the routines [37]. The second 
subtask was to formally specify the mode-control panel logic of a Boeing-737 experimental 
aircraft system using Larch (the specification language used by Penelope) [38]. 

A joint project between ORA and Charles Stark Draper Laboratory (CSDL) has been 
initiated. The CSDL has been funded by NASA Langley to build fault-tolerant computer 
systems for over two decades. They have recently become interested in the use of formal 
methods to increase confidence in their designs. ORA has formally specified an important 
circuit (called the scoreboard) of the Fault-Tolerant Parallel Processor (FTPP) [39] in Cal- 
iban [40]. Work is currently underway to formally verify the circuit. 


Boeing Military Aircraft Co. 

The Boeing Company has been sponsored by NASA Langley to develop advanced validation 
and verification techniques for fly-by- wire systems. As part of the project, Boeing is exploring 
the use of formal methods. The goal of this work is two- fold: 1) technology transfer of formal 
methods to Boeing, and 2) assessment of formal methods technology maturity. 
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NASA Langley has been involved in a cooperative research partnership with Boeing to 
facilitate the acceptance and adoption of this high-risk, high-payoff technology by Boeing. 
The first step was to demonstrate that formal verification of “real” hardware devices is, in 
fact, feasible. The first Boeing tasks concentrated on applying the HOL hardware verification 
methodology to a set of hardware devices. With the assistance of a subcontract with U. C. 
Davis, Boeing verified a set of hardware devices, including a microprocessor[41], a floating- 
point coprocessor similar to the Intel 8087 but smaller[42, 43], a direct memory access (DMA) 
controller similar to the Intel 8237 A but smaller [44], and a set of memory- management 
units[45, 46]. U. C. Davis also developed the generic-interpreter theory to aid in the formal 
specification and verification of hardware devices[47, 48, 49], and a horizontal-integration 
theory for composing verified devices into a system[50, 51, 52, 53]. 

After demonstrating the feasibility of verifying standard hardware devices, Boeing was 
ready to apply the methodology to a set of proprietary hardware devices being developed 
inhouse for use in a number of aeronautics and space applications. NASA sponsored a Boeing 
engineer to work with the Processor Interface Unit (PIU) design team to formally specify 
and verify the device. Although the NASA contract with Boeing will end in FY93, Boeing 
has already capitalized on the NASA program and has started their own IR&D effort to 
continue applying formal methods to the set of devices. 

The cooperative research effort with Boeing has helped NASA Langley to assess the 
maturity of formal methods technology with respect to state-of-the-practice digital flight- 
control systems. First, Boeing was tasked to analyze the suitability of the VIPER chip for 
application to digital flight controls and to assess the design/verification methodology used 
on the VIPER[54] 4 . The generic-interpreter and horizontal-integration theories developed at 
U. C. Davis provide models to guide the specification and verification of hardware devices. 
Application of formal methods to the PIU has demonstrated that formal methods can be 
practically applied to the digital hardware devices being developed by Boeing today and has 
given NASA insight on how to make the process more cost effective. 

Work is also progressing on a methodology for formal requirements analysis for aircraft 
systems[58, 59]. This work, being performed under a subcontract to California Polytechnic 
State University, includes development of a Wide-Spectrum Requirements Specification Lan- 
guage (WSRSL) and prototype tools to support the language. A set of requirements for an 
Advanced Subsonic Civil Transport (ASCT) developed by a Boeing engineer under previous 
NASA funding is being rewritten in WSRSL to demonstrate the use of the language and 
toolset. Since WSRSL is a formal language, the specification can be formally analyzed for 
syntactic correctness, completeness, and consistency. NASA Langley is currently evaluat- 
ing WSRSL as a candidate requirements specification tool for the fly- by-light/power- by-wire 
project. Future plans include possible development of an automatic translator to Ehdm (SRI 
International’s theorem prover) to facilitate verification of functional correctness as well. 

4 NAS A Langley has just completed a 3 year Memorandum of Understanding (MOU) with the U.K. 
Royal Signals and Radar Establishment (RSRE) in formal methods. The MOU focused on the VIPER 
microprocessor and the verification methodology used in its development. Computational Logic Inc. and 
Langley inhouse researchers also performed assessments of the VIPER project[55, 56, 57]. 
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NASA FM Repository 

An anonymous FTP account has been set up at Langley to make the research results readily 
available. Formal specifications, research papers, and other useful information will be stored 
in machine-readable form. To access this repository, one must issue the following command: 
“ftp airl6.larc.nasa.gov” . One then supplies “anonymous” as the user name and his FTP 
address as the password. 


Summary 

Although the NASA program covers a wide-spectrum of theoretical and practical problem 
domains, it is strongly focused on the goal of designing a fault- tolerant reliable computing 
base which can support real-time control applications. Much progress has already been made 
in applying formal methods to critical subsystems such as clock synchronization, Byzantine 
agreement, voting, etc. The challenge ahead is to integrate all of these activities to accom- 
plish a complete verification of the total RCP system and to continue the transfer of this 
technology to the aerospace industry. 
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Welcome and Introduction 


Charles Meissner, Jr. 

Head, System Validation Methods Branch 
NASA Langley Research Center 
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WELCOME 

AND 

INTRODUCTION 


FORMAL METHODS WORKSHOP 
NASA LANGLEY RESEARCH CENTER 
AUGUST 11-13, 1992 


Charles W. Meissner, Jr. 

NASA Langley Research Center 


NASA ORGANIZATION 
VERTICAL CUT TO SVMB 
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LANGLEY FAULT-TOLERANT DIGITAL SYSTEMS 
HISTORICAL PERSPECTIVE 


CA. 1972 ARCS 

CARSRA 

SIR 

RMP 

CARE III 

LIC SORWARE 

IAPSA 

SURE/ASSIST 
CA. 1992 AIPS 


F-T SYSTEM DESIGN 
RELIABILITY ANALYSIS 
F-T COMPUTER 
F-T COMPUTER 
RELIABILITY 
S/W ERROR ANALYSIS 
F-T DFCS DESIGN 
RELIABILITY ANALYSIS 
DISTRIBUTED F-T SYSTEM 


ULTRARELIABLE DIGITAL AVIONICS 


CONTROL SYSTEMS BECOMING THE PRACTICAL EQUIVALENT OF PRIMARY 
STRUCTURE 

• U.S. FAR 1309-1 Requires P(fail)<10 for statistical compliance 

• Reliability can’t be estimated to this level 

. Experienced engineering and operational judgement used for compliance 


FAULT-TOLERANT DIGITAL SYSTEMS ARE NECESSARY FOR PRACTICAL 
REALIZATION OF ADVANCED CONTROL 
. Analog functionality insufficient for advanced control 

• Analog too high In size, weight, power 

• Digital system components not adequately reliable - use redundancy to 
increase reliability 


25 



FORMAL METHODS FOR 
FLIGHT-CRITICAL SYSTEMS 


• The only scientifically satisfactory approach to aspects of the 
digital validation process is through reasoning 


• Formal methods may become important sooner than is 
commonly supposed in the aerospace community 


• SVMB has put an emphasis on formal methods 

• Industry/FAA focus is essential feature of our formal methods 

work ; 

‘ =-- :> ' . ■ I 
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Why Formal Methods? 


Ricky Butler 

System Validation Methods Branch 
NASA Langley Research Center 
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• HiMAT crash landed without landing gear due to a design 
flaw. Traced to timing change in the software that had sur- 
vived extensive testing. 
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What Enables Ultra- Reliability Quantification For Physical Design Diversity Problem 

Failure 





« # • 



» • • • • 
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tions — A calculus for analyzing and predicting the behavior of 

systems — formal verification 

• Computers can provide speed and accuracy for the calcula- 
tions 
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The Maturity of An Engineering Disciplin 
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PROVE: EX EC<{ = MrtjH EX ECi , , (5 (| , (<))) 
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Specifying Adding/Deleting an Entry 
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What Makes a Technique a “Formal Method?" Expressibility Vs. Proving Efficiency 
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Tutorial 

Design Specification Techniques 

Ben DiVito 

ViGYAN 
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Tutorial on Design Specification Techniques # Statement of example problem 
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Tutorial 

Code Verification Techniques 


C. Michael Holloway 

System Validation Methods Branch 
NASA Langley Research Center 
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Tutorial on Code Verification Techniques Outline 
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{Final assertion under variable 
substitutions due to assignments} 



Software Example: Linear Search 

Method of Proof (continued) English Specification 
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Accumulating deductive knowledge 



Mechanical Theorem Provers (continued) Concluding Remarks 
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The FAA DFCS Handbook 
Formal Methods Chapter 

John Rushby 

SRI International 
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The chapter /s o Abstract data type and its implementation (stack) 

o A very detailed exposition of issues in application of formal 0 Design-level moderation (library) 

methods to critical systems ° Algorithm (Oral Messages algorithm for Interactive 

o Addressed to an audience wider than certifiers (developers, Consistency) 

managers, engineers) 
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be done formally, but are different from conventional formal • Early lifecycle 

methods pro: That’s where the serious errors are; that's where the 

concern is; few other rigorous techniques available 
Con: front-loads development time and cost 


Validation of Specifications 
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allow it to be documented 



Some Successful Applications of Formal Methods 
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Commentary on DO-178B (formal methods allow analysis to . Avai|ab|e for revjew jn a couple of weeks 

replace or supplement reviews) 


Survey of State-of— Practice 
Formal Methods in Industry 

Dan Craigan 

ORA Canada 
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Overview of Presentation 


Survey of State-of-Practice: 
Formal Methods in Industry 


• Purpose, sponsors and researchers. 


• Method for conducting survey. 


Dan Craigen 
ORA Canada 

danQora.on.ca 

NASA Langley, Virginia 
11 August 1992 


• Cases: An overview. 


• Example case: TCAS. 


• Example feature: Tools. 


• Observations. 




2 


Purpose, sponsors and researchers 


• To provide an authoritative record on the prac- 
tical experience to date. 

• To better Inform industry and government 
bodies developing standards and regulations. 


Purpose, sponsors and researchers 
• AECB, NIST, NRL. 


• To provide pointers to future research and 
technology transfer needs. 


• Dan Craigen, Susan Gerhart, Ted Ralston. 


• Value added: Case studies and analysis. 
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Method for Conducting Survey 


Method for Conducting Survey Process 

• Initial questionnaire. 

• Literature review. 

• Structured interviews (Second questionnaire). 

• Raw notes, case report, review. 

• Review committee. 

5 


Method for Conducting Survey 
Analytic framework 

• Product features. 

• Process features. 

• FM R&D summary. 

• Key events and timing. 


Questionnaires 

• Initial questionnaire and structured interview 

• Organizational context. 

• Project content and history. 

• Application goals. 

• Formal methods factors. 

• Formal methods and tool usage. 

• Results. 

6 

Method for Conducting Survey 
Product Features 

• Client satisfaction. 

• Cost. 

• Impact of product. 

• Quality. 

• Time-to-market. 
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Method for Conducting Survey 
Process Features 

• Cost. 

• Impact of process. 

• Pedagogical. 

• Tools. 

9 


Method for Conducting Survey 
FM R&D Summary 

• Methods: specification; design and implemen- 
tation; validation and verification, [uses] 

• Tools: language processors; automated rea- 
soning; other tools, [tools] 

• Recommendations to FM community, [needs] 


Method for Conducting Survey 
Process Features 

• Design. 

• Developing reusable components. 

• Using existing reusable components. 

• Maintainability. 

• Requirements capture. 

• V&V. 

10 


Method for Conducting Survey 
Key Events and Timing 

• Starter. 

• Booster. 

• Status. 


11 
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cases: An overview 


Cases: An Overview 

• CASE 

- SSADM toolset; commercial; /. 

- 340pgs Z/English; 550 schemas; 
37KLOC obj. C; 16.5 linos/day 

• CICS 

- Transaction processing; commercial; Z; 
PS/2 tools. 

- 268KLOC new/modified code; 
50KLOC traced to Z specs; 

9% improvement in cost; 

60% reduction in APARS. 


13 


• Clean room 

- COBOL structuring and Attitude control; 
commercial and government; 
functional specs, and testing. [Method] 

- 80KLOC; (20KLOC reused; 18KLOC 
changed; 34KLOC new) 

- 34 lines/day; error rate of 3.4/KLOC 
( 1 /20th industry average). 

• Darlington 

- Shutdown system; regulatory; A-7 style and 
program function tables. 

- SDS1 : 1362LOC Fortran; U85LOC As- 

sembler 

SDS2: 13KLOC Pascal (??). 

14 


Cases: An Overview 

• LaCoS 

- Engine management and a distributed con- 
troller; ESPRIT and commercial; 

Raise [Method]. 

• Multinet Gateway 

- Network security; NCSC; GVE, etc. 

- lOpgs math; 80pgs Gypsy, 6KI.OC OS. 

• SACEM 

- Automatic train protection system; safety 
critical and RER; B, Hoare triples; B tool. 

- 9KLOC verified code; Total of 315,000 per- 
son hours. 


Cases: An Overview 

• TBACS 

- Smartcard security application; security; FDM. 

- 300 lines of FDM; 2500lines of C. 

• Tektronix (oscilloscope) 

- Reusable software architecture; commercial; 

Z; Fuzz. 

- 200KLOCof code; 15 pgs of Z specs (twice). 

• T CAS 

- CAS Logic and surveillance; regulatory; state 
charts with DNF tables. 

- 7KLOC of pseudocode; specs about the 
same size. 

16 
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Cases: An Overview 

• Transputer 

- T-800 FPU, VCP; commercial; Z, HOL, 
mathematics. 

- FPU: lOOpgs Z; 4KLOC Occam; VCP about 
10 6 states. 

• HP-AIB 

- real-time data-base; commercial; HP-SL. 

- 55pgs HP-SL; 1290 lines of spec and design; 
4390 lines of code. 


Example case: TCAS 

• Traffic Alert and Collision Avoidance System. 

• TCAS I, II, III. 

• Congressional fiat (1993). 

• Grand Canyon collision. 

• Time span from early 80s. Leveson in June 
1990. 


17 
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TCAS 

• Players: RTCA Inc. (SC 147), FAA, UC Irvine, 
Mitre, Lincoln Labs. 

• Interview profile: Leveson, Nivert, Lubkowski, 
White. 

• CAS Logic and surveillance system. 

• 7 KLOC pseudocode. 

• 700 pages English description. [Terminated) 

• Loss of intellectual control- 

19 


TCAS 

• FM for safety analysis, [model checking and 
automated deduction) 

• Statecharts. 

• DNF tables for conditions. 

• Iteration on notation. 

• Strong support from SC 147 and industry. 

• Currently at IV&V [15 pys over 8 months). 

20 
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Product features 


Client satisfaction 

\ 

Cost 

n/a 

Impact of product 

n/a 

Quality 

n/a 

Time to market 

n/a 


General process features 


Cost 

n/a 

Impact of process 

+ 

Pedagogical 

+ 

Tools 

n/a 


T CAS (Key Events) 


• Starter: FAA seeking better rqts. for deployed 
and troublesome system; Leveson looking for 
demo project. 

• Booster: SC 147 willing to accept new ap- 
proach; Readable notation. 


Specific process features 


Design + 

Developing r. comp, n/a 
Reusing r. comp. n/a 

Maintainability n/a 

Reqts. capture + 

V&V n/a 


• Status: CAS Logic formalism and pseudocode 
in IVV. Surveillance logic current. 
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TCAS (R&D) 


TCAS (R&D) 

• Uses: Mod. to Statecharts 

- Concurrency as parallel state machines. 

— Tabular notation. 

— Specs, reviewable and IV&V. 

- CAS Logic from pseudocode and English. 


• Tools: LaTeX. 

• Needs: 

- Safety analysis tool. 

- Automated deduction and model checking. 

- Well-formedness checker. 

— Foundational issues. 

• Conclusions: successful transition and applica- 
tion. 


24 
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Tools (Usage) 


Tools (Usage) 


• CASE (SSADM): Prototype Z parser and type- 
checker. 

• CICS: PS/2 based toolsuite w/ editor, type- 
checker, semantic analyser (Z). 

• Cleanroom: Editors, waste paper basket. 

• Darlington: Microsoft Excel. 

• LaCoS: Raise toolset. 

• Multinet: GVE, Extractor. 
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Tools (Needs) 

• CASE (SSADM): schema expander, enhanced 
editor, browsing and X-ref. 

• CICS: schema expander, semantic analyzer (for 
all Z), configuration management. 

• Cleanroom: Extracting and tracking verifica- 
tion events. 


• Darlington: automated deduction, POG, book- 
keeping. 

• LaCoS: Experience with automated reasoning 
tools. 


• SACEM: B. 

• TBACS: FDM, scrolling, pencil and paper X- 
ref. 

• Tektronix: Fuzz editor, typechecker and pretty 
printer. 

• T CAS: La TeX. 

• Transputer: Occam transformation system, in- 
house refinement checker. 

• HP: HP-SL syntax checker. 

26 


Tools (Needs) 

• Multinet: Better automated deduction, improve- 

ments for industrial scale, soundness, better 
notation. . . 

• SACEM: Better integration with other V&V. 

• TBACS: Better interface; large expressions and 
many proof steps. 
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Tools (Analysis) 


Tools (Needs) 

• Tektronix: schema expander, refinement proof 
tool, pre-condition calculator. 

• T CAS: safety analysis tool, automated deduc- 
tion, language checker, soundness. 

• Transputer: refinement checker for large state 
spaces. 

• HP: Language checker and better notation (not 
ambitious!). 


Did the formal methods tools help or 
hinder the development of the product? 
Were the tools reliable? 

CA Cl CL DA LA MG SA TB TE TC TR HP 

+ 0 n/a 0 0 + + - n/a + 0 

• Not a large role (lack of tool support). 

• Problems due to newness and primitiveness. 

• Need for language checkers, bookkeeping. 

• Don’t be too ambitious. 
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• Automated deduction in critical applications. 

30 


Observations 

Features: 

• Definite positive influence on design, require- 
ments, V&V, and pedagogical. 

• Positive influence on 'impact on process' and 
quality. 

• Neutral on cost. 


Observations 
Formal methods 

• Methods: state machine; lst-order predicate 
calculus; reviewability; complete refinement. 

• Tools: Language processors; bookkeeping; 
browsing; x-ref. 

• Needs: Integration with other V&V; concur- 
rency and timing; lower barriers of entry. 
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Availability of Report 


• Availability within 2-3 months. 


• Send email to dan<5ora.on.ca, or mail to: 


Dan Craigen 
ORA Canada 

265 Carling Avenue, Suite 506 
Ottawa, Ontario KlS 2E1 
Canada 
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Formal Modelisation 

Susan Gerhart 

National Science Foundation 
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Software Engineering for a 
"Formal Methodist” 


Modelisation 

Sure you've proved it correct, 
but what does the system REALLY do? 

Susan L. Gerhart 
sgerhart@nsf.gov 


Subjects: 

The SACEM Case 

(continued from Dan Craigen's presentation) - 
how FM was embedded in an industrial process 

Issues of "modelisation" 


Requirement* Mathematical model of 810 system ttuji allows 

property exploration 

Specification “the system" expressed in mathematical 

notations 

Design Operation decomposilions and data 

refinements 

Implementation Code ♦ Assertions ♦ Assumptions 

Validation Spec. Execution or proofs ol properties 

Verification Identification and discharge of correctness 

obligations 

Documentation ... Prose and diagrams that go with the 

mathematical notation 

Life Cycle. „ Get the specification right and agreed upon 


Background Point of View 


SACEM: 

Train control for the Parts Metro 


The Job: 

Shorten the train intervals to 2 minutes to avoid a new Parts line 
Convince the Pans Transit Authonty the system was safe 

Dim 

Build up an international business in safe train control systems 


Who: 

G fiC Alsthom/ Matf a/CSE E ♦ Pans Transit Authority 

The Process: 


ig 7 Qs Decided had to go with new soltware ami 

hardware 

Explored fault tolerance, discovered proof 0! correctness techniques, 
did safety studies 

1900 s built prototypes 

verified code one way. 

found new way to specify and verify. 

worked with authorities to demonstrate safety, 

brought on-line 

1990 s demonstrated capability on other sy stem s. 

commercializing tools used in the process 


SACEM System 



Challenges: 

• Different kinds ol “rolling stock’ to deloci, 
some protected and some not 

• Variations in track-beacon technology, tunnels & rivers. 

• Getting the wain “home’ when it's system does la# 

• Encoded single processor (rather than complex synchronized 
multi -processor) - as fad safe as possible 


The Results: 

Verification was demonstrated as an addition to simulation, without 
excess cost and with significant added assurance 

Specification and modelisation matured and an industrial process 
was defined 



SACEM lessons for Formal Methods 

An industrial process has been pul in 'place that is evolving 
toward 

Understood and documented 
Moasurud and predictable 
Rogardod as cost dtioclive 
Toot supported 

Probably comparable to MoD 0055 

Many techniques can play together, 

(although not in concert yet) 

SADT loc graphical system decomposition and analysis 
FSM (Graphcot) simulator 
Hazard analysis 

Operational scenarios (600 of them) 

Real time design simulation 
Prototyped system 

Code venlicalion & specilicalion rolinement 

Technology Transfer problems could be overcome 

A manager understood and stuck with it 

The customer was educated (and did their own ihmg) 

Proving coukJ be crodibly compromised 
Modutisulion will holp synthesize their results 



Total: 315,000 hours (V&V = 1.5 x Development) 
formal prool 32 4% 

module testing 20 1% 

functional losting 25 9% 

re- speculation 2t 6% 



Modellsation 


) all Ihe stakeholders to understand 


tmenoeo system. ouusuin« 
mathematical modeling, etc. 


In SACEM. 

Tracks, trains, beacons, encoded mproc. 

Safety pnnciples 

The description notation itself 

The process of using the description 

Problems encountered with modelisation in SACEM: 


laborious code description disconnected from Ihe theorem’ 

Concurrency dillicuft to express in top level modot 

Different representations, dillerent analysos were used tor 
assurance (see tools HsJ) 


Many kinds ol system views: certifier, railway switching, 
microprocessor developer, lorinal voiilior 


Rolmamonls were OK. but there was u code gap (now 
generated) 


Carry-over from Requirements 
Analysis 

Given a language and tools, how do you express the 
requirements and model the system ? 

Translate English and diagrams to sets, logic, etc. 
and translate back and forth, but 

how do you read and clwck these? 
what (kagrammatic techniques match FMs? 

CORE, JSD, GIST, SADT etc. provide: 

standard system representations 
ways to get dillorent viewpoints 
domain modeling techniques 
Software process modeling offers: 

Guidolines tor use 

Basis lor data collection and eventual metrics 
Opportunities lor mlugution. eg with touting 
Basic appoarance ol manageability 


v 
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Moderation Process 

identification 

Enuties 

Constraints among entities 
Operations and Ihetr parameters 

Representation 

Entities become values of a type 

Types must be defined to construct, modify, and examine their 
contents "" -- 

Representation issues are considered, e g ordering, dupScafion, 
primitive types, attributes 

Additional properties of the data types from requirements 

Operations defined with their parameters 

Restrictions are expressed as pre conditions 

its effects are defined in terms of parameter values before and 
after execution 

System invariants are formulated from properties that the system 
is required or expected to have 

Invariants are proved by induction; 

(And a collection of definitions is built up) 


The limitations of the model are identified, e g 
Omitted operations or data details 
Implicit definitions 

Assumptions about the operating environment 
(system and users) 

Degree of concurrency expressed 

Reliability of communicaiion media 

Performance, resource, and security requirements that must be 
met by the implementation 

A plan for using the model is developed, e g. 

Identifying the riskiest or least understood part for further 
anafysw or refinement 

Iteration toward more extensive models 
Formal proof of properties ol the model 
Validation, e g. by 
Prototyping from Ihe modqJ 
Reviews, inspections, and other peer analyses 
Animation of the modef 

Scenarios to stimulate response from customers 


Summary 


SACEM Case 


"Complete" application of formal methods 

Shows us potential for integration of FM into broader 
system engineering 

Displays interaction of problem domain and formalization 
Moderation 

Process aspecF to add to FMs as languages & tools 

Integration of standard computer science with application 
domains - — — — - = . ■ 

Challenge to FM Vendors: 
write down your process model 

and 

show how moderation Vs performed 
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NASA Format Methods Workshop 


1 1-13 August 1*92 


FormaFMetTiods Tec hnolo gy 
Insertion into the FTPP 

Objective: 

Use formal specification and verification of 
critical FTPP hardware and software 
components to reduce the Incidence of 
com mon-mode failures du e to specification 
and implementation errors 

Formal methods do not help avoid many sources 
of common-mode failures 

environmentally-induced faults: EMI, 
radiation, heat* water, corrosives, sand (!) 

Formal methods are not the only solution to 
common-mode fault avoidance, removal, and 
tolerance 

Mature components, standards compliance, 
design automation toois.ruthiess persecution 
of complexity, conservative design practices, 
simulation, testing, various CMF 
detection/recovery mechanisms 


Fault Tolerant Parallel Processor 
(FTPP) 

High-throughput high-retiability/availabllity 
computer for hard real-time applications 

Uses many Processing Elements (PEs) in 
parallel for high throughput 

Uses redundant PEs for high reliability 

Tolerates arbitrary failure manifestations 
(“Byzantine Resilient") 

Designed primarily to tolerate uncorrelated 
ha rd ware fault s 

Programmed in Ada 


NASA F<w:ra Methods Wwishtv ilti fSft* 3 


NASA forma! earft&d* W riks&p 1 Y-t 3 August IM2 4 
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Fault Tolerant Parallel Processor 
(FTPP) 


Current FTPP Applications 


Can trade throughput (parallelism) for 
reliability (redundancy) In real time 

Can be dynamically reconfigured to optimize 
mission reliability and availability 

Supports mixed simplex, triplex, and 
quadruplex redundancy 

Allows heterogeneous processing resources 
Parallelism ~ transparent to programmer 
Fault tolerance ^ transparent to programmer 


riA&A Formal Methods Workshop fi-i 3 August \992 


"The Army Fault Tolerant Architecture (AFTA) 
Program" 

Funded by: Army Electronics Integration 
Directorate f NASA 

Application: Helicopter TF/TA/NOE/FCS 

,J Heterogeneous FTPP" 

Funded by: Army Strategic Defense 
Command 

Application: Battle Management 

"Fault Tolerant IMU Processor" 

Funded by: a commercial aerospace company 
Application: IMU processing 


NASTFormal Msthodt Workshop 1 M 3 Aupusl \992 


Cluster 3 (C3) FTP P 


FTPP C3 Architecture 


Thlrd-generation FTPP 

Processing Elements 

Support 3 to 40 PEs per cluster 

680x0s, 80960s, MIPS R3000S, 1860s, or 
DSP32C signal processors 

Network Elements 

100 Mbit/sec fiber optic interchannel links 

facilitate fault containment and physical 
dispersion 

Standard bus Interface to Processing 
Elements 

Software 

XDAdaTM-based operating system with 
CSDL extensions 



NASA formal Methods Workshop 11-13 August 1*M T 


NASA formal Mslhods Workshop 1 M3 Augusl 1 W2~ 
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Layered View of FTPP 


Components of FTPP Suitable for 
Formal Methods Insertion 



Processing Element 
Network Element 
FCR Backplane Bua 
VG Synchronization Software 
Task Scheduling Software 
inter-VG Communication Software 
FDIR Software 


NASA For maTMo mod s WoTtTsti op 11-13 August 1 992 S' 


NASA Formal Methods Workshop 1143 August )M2 10 


Processing Element 

Formally specified / verified microprocessor can 
be used in FTPP 

Processors Interface to FTPP over standard bus 
(e.g., VMEbus) 

Not all processors In FTP P need be formally- 
verified 

Could use small number of formally verified 
processors to form quad or triplex Byzantine 
resilient core VG which runs a simple verified 
kernel 

Core VG responsible for monitoring other 
VGs (Including CMFs) and resetting offenders 
using votad_ra sat capability of NE 

ThroughpuT of core^VG ncrt r$sue.,.can get 
desired throughput adding higher-throughput 
VGs in a heterogeneous parallel processing 
configu ration ~ 

All VGs communicate using BRVC - 


Network Element 

Executes performance-critical Byzantine 
resilience algorithms - - - 

Provides BRVC abstraction 

Generates vole, FTC, link, and other syndromes 

All components execute specifiable and verifiable 
algorithms 

Bus interface 

Voter / syndrome accumulator 
FTC 

Global Controller 
Scoreboard 

Substantial body of related work from formal 
methods community is relevant to these functions 


NASA V urr i Mu mods VVo?*shot’ !M.1 august 1992 ft 


NA5U FomimJ Method* Workshop fl-13 August 1992 
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HAS A forn^Malhod* Workshop U-tiTAuguil 1982 13 


FCR Backplane Bus 

Backplane bus used for PE-NE communication 

NE partitioned into bus -dependent and bus- 
independent sections 

Can retrofit NE to formally specified/verified 
backplane bus by modifying bus-dependent 
section 

Formal model of backplane bus needed 

Backplanes are a common component of 
many systems 

A formally specified and verified backplane 
could find wide use In critical systems 

Powerful building block for ullrareliable systems: 

Formally specified and verified processor 
resident on formally specified and verified 
backplane bus card 


NASA Formst M«|hods Workshop ’ 1 1-1$ Au0uiM992 


Byzantine Resilient Virtual Circuit 
tnter-VG Communication Abstraction 


Smut* VOl 


»««r‘ 

ikUci.il 

f l_x UIIW.HC vrj. 



Massaga* sant by non-faulty mtmbars of a sourca VC ara 
correctly dtllvartd to tha non-faufty members ol recipients 

Non-faulty mambars of raciplant VQa rscatva massage* In tha 
order atnl by lha non-faulty mambar* of tha sourca VG 

Non-faulty mombara of raciplant VG* racaiva massaga* In 
Identical order 

Tha absoluta tlmat ol arrival ol correapondlng massaga* at tha 
member* of recipient VG* differ by a known upper bound 5 

Tha lima between a valid massaga transmission roquest and 
massaga dellvary post***#* a known uppar bound t 

The BRVC abstraction is supported by the NEs 
WliA Formal Haifiods Work ship 1 1 • 1 3 Auguil \ wT i 


VG Synchronization 

VGs are synchronized upon periodic timer 
Interrupts (e.g., at 100 Mz) 

Timer interrupts occur within a bounded skew on 
all members of VG 

Upon timer Interrupt a VG performs a 
synchronizing act (l.e., message passing using 
BRVC) 

Send message to self 
Await reception 


i I •UK' t’H 

IMG Member 



► 'a — o ► 


TJA9A formal Method a Workshop ' nilAugutUMJ " * iti 
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Inter-VG Communication 


Rate Group Scheduler 

FTPP C3 umi timer-based preemptive rate group 
scheduler 

Variant of rate-monotonlc scheduling optimized 
for Iterative task suites having harmonic iteration 
rates 


Tasks Interact only at frame boundaries 



FTPP OS schedules appropriate tasks at each 
frame boundary 


Frii«« Boundary 

Ccmpfated RGa 

SurtPd BG* 

7-0 

4, 1. 2, 1 

4. 3, 2, 1 

at 

4 

4 

1-2 

4.3 

4.3 

2-3 

4 

4 

3-4 

4. 3,2 

4, 3.2 

4-5 

4 

4 

5-4 

4,3 

4, 3 

4-7 

4 

4 


FTPP tasks communicate using message passing 

queue jee a a age OS call places message onto 
outgoing queue to NE 

FTPP OS determines destination VG from task- to- 
VG mapping table 

OS transmits message queue to destination VG 
using BRVC 

Recipient VG ( s OS reeds message from NE and 
places into destination task input message queue 

retrieve_aweeege OS call accesses appropriate 
task Input queue and delivers message to task 


All KhrtutinQ ami kUif:.YG GonuminiMtlon 



fcASA FOTuTUMKods Wait Shop 11*13 August l®W if 


10i|A?oinnal Methods War h shop 


11-13 August iImT ’»• 


FDIR 


FOIR partitioned for vafidatabffity 

Local FDIR runs on each VG 

System FDIR runs on designated VG (e.g., 
formally verified VG) 

Algorithm: - . -t- , . ^ 

local FDIR 

Executes seif tests 

Scrubs RAM (Indepen dent of 
characteristics of application task suite) 

Periodically transmits self test re suits to 
ayatam FDIR via "presence message" 

System FDIR 

Examines contents and syndromes of 
presence messages to diagnose senders 

Fsfiurs to receive presence message within 
bounded time Impi^s common-mode failure 
of sender 


Fault Recovery - * 

Many recovery policies possible in FTPP 

Reduce redundancy level 

Reintegrate faulted component 

Replace faulted component with spare 

Syste m FDIR de termines appropriate recovery 
action and sHttar^ — 

transmits recovery commands to local FDi lor 
localized recovery or 

performs global system-level recovery 

Must show that system FDIR determines correct 
recovery action as s function of diagnosed 
component 

Must show that local or systsm FDIR correctly 
carries out specified recovery 


MlSA fmmtt Math*** Worts* op" " Jf3 August i»*7 If 
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Heterogeneous Kernels on FTPP 

Not ail kernels in FTPP need be Identical as 
long as (hey can communicate using BRVC 

FTPP can host rate group scheduler on 
production VQs and small formally verified 
kernel on formally verified VGs 

Message passing through 
synchronization so Ihe formally vei ifted 
Hemal wo uld no* explicitly perform 
synchronization of redundant sites 

The formally verified VG would execute the 
system FDIR function 


tiASA Form* Method* Workshop IMS August 1 M2 


Work in Progress: Scoreboard 
Specification and Verification 

Currently collaborating with ORA to formally 
specify Scoreboard 

Scoreboard Is a critical component of FTPP 
Comprises approximately 50% of NE circuitry 
Enforces BRVC abstraction 
Business Model: 

FM experts working closely with engineering 
staff having little exposure to formal methods 

Separate funding (Draper not specifically 
funded to collaborate) 

Scoreboard described in VHDL and constructed 
using automated synthesis (Synopsys) 

VHDL used as common language between Draper 
and ORA 


T4ASA For mil Methods Workshop 1 M3 August 1 992 


Conclusions from Scoreboard 
Specification and Verification 

Formalization of Scoreboard requirements 
uncovered several specification omissions and 
ambiguities 

Collaboration would have been closer and Impact 
on daslQn greater If Draper had been specifically 
funded to participate 

Incremental cost on a $2.4M brassboard 
development program Is small 

Benefit to cost ratio la vary high during the 
conceptual study and detailed design phases 


T m*A forms! t Ewog Wotkihop TTO Augustin 


Work Planned and Critical Needs 

Work Planned 

Components similar to remainder ol NE (i.e., FTC, 
voter) have been formally specified/verified 

Would like to adapt this work to FTPP 

Actively seeking FV processor to design into 
FTPP 

Planning to develop selected subset of RCP 
software for FTPP 

Critical Needs 

Viable processor 

Formal subset of VHDL, with nonempty 
intersection ol synthesizeable and formal subsets 

Continued formalization of FTPP NE 

Formal model for FCR backplane bus 

Formalization of critical OS functionality 

Business model for formal methods Insertion 


NASA formal Method* Workshop * 1 - 13 Augutt lM0f 
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Introduction and Purpose 


Harlan Mills and SEW 


• To cover 

1. Some IBM involvement in Formal Methods (FM) 
projects 

2. A perspective on difficulties of technology transfer 
(beyond a single project) 


e Purpose is not to 

- sell the "IBM approach" 

- argue against feasibility of FM 


e Purpose is to 

— learn from other FM technology transfer projects 

- suggest some possible future directions 


• Mills led massive software engineering education 
program 

— Software Engineering Workshop was cornerstone 
| 2 week course 

| Taught to all programmers 
| Required to pass final exam 

• SEW centered on mathematically-based verification 

- Functional instead of axiomatic 

| model oriented instead of property oriented 
| designed to scale up (stepwise refinement) 

| easier for programmers to understand 

- 2 pieces 

1. Deriving program functions 

I Trace tables (basically manual symbolic 
execution) 

| Recurson instead of loop invariants 

2. Module-oriented 

| abstract data types 

1 constraints/closure on state data (abstract 
state machine) 
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Harlan Mills and SEW 


... 


Cleanroom 


• SEW designed to be practical 

- relatively informal 

- scaled up via abstraction/refinement 

- lots of examples and exercises 

- final test : pass/fail 

e Advocated for all programming, not just critical parts 
e no support beyond education 

- no tools 

- no consulting 

• General reaction was that it was impractical 

- too tedious 

- seemed only for toy problems 
e Did not gain widespread use 

Cleanroom ... 

e Showcase project was COBOL/SF 

— Transforms unstructured COBOL into structured 
COBOL 

- 52,000 SLOGS developed using Cleanroom 

- Results 

| 740 SLOCS / labor month 

| 3.4 errors / KSLOC (before first execution) (70 

avg incl. LIT) 

| no error ever found during operational use 

e Advocacy of Cleanroom continues 

- Widespread use not yet attained 


• Named after silicon chip manufacturing environment 


e Built on SEW foundation, adding 


- Continuous inspections (SEW style verification) 


Statisical testing (MTTF prediction) 


• Advertised through case studies, not classes 


- Demonstration projects using highly skilled 
developers 


- To demonstrate benefits 


- To show it can be done, it is practical 


e Demonstrations projects were success stories 


Aug TO 


SEDL 


• Intended to support SEW/Cleanroom verification 
concepts 

• Built as an extension to Ada 

• SEDL compiler generates Ada 

• Supports design execution 

- though SEDL generated code my be inefficient 

• Includes 

- Abstract data types (set, list, map, etc.) 

- User defined data models 

| model vs. representation 
| constraints 

-» Supports mathematical notation 
| {X in CHARACTER : x / = 'Q'} 

| exists X in S : P(X) and exists Y in T : P(Y) 

| P>1 and not (exists Q in 2,. P-1 : P rem Q = 0) 

• Use of SEDL is not widespread 


- But there is a lot of interest in Cleanroom 


AU9TO 


AugTO 
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Other Projects and Approaches 


Note on Quality Emphasis 


• Application above the code level 

- Development of a "Box Structures" design 
language 

- Development of a "Box Structures" approach to 
requirements 

- Results 

| SA/SD approach to design most popular new 
approach 

| Requirements still written in English 

e Emphasis on SEW concepts 

— Concepts generally well accepted 
— Loss of rigor reduces mathematical basis 


Summary 

# Goal was to increase the use of format mathematical 
approaches to software development (beyond a single 
project) 

1. First through education 

2. Then through demonstration projects 

3. Then through tool support 

4. Then by making methods more practical 

5. Finally through direct support (consulting) 

e There have been successes 

- not nearly as widespread as desired 


e This story is not unique to FM 

- The problem is with technology transfer, not with 
technology 



• Software quality has extreme emphasis 


- Great emphasis on process improvement 

- Serious attention given to quality goals and 
measurement 


- Quality motivation programs 


| awards and recognition 


| Manned Flight Awareness program 


• There is willingness to work hard and invest for quality 


• The question is not what or how much but how 


- FM is generally perceived as not helping 


A 09/97 12 


Conclusions 


• Conclusion: Technology Transfer is very hard, even 
with 

- extensive education 

- tools support 

- demonstrated successes 

• Possible future directions 

- More consulting ("hand holding") (product 
champions) 

- Use only a core group (FM may just not be for 
everybody) 

- Require use of FM (selected groups) 

- Success story close to home 

| technology transfer diminishes rapidly as a 
function of distance 

| long term committment is required (success 
story requires continued follow-up) 

- Different formal method(s) 

- Different tools (e.g., theorem prover) 


A 09/9? 
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Reliable Computing Platform 
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Design Philosophy Formal Methods is Enabling Technology For 
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Reliable Computing Platform RCP’s Sequence Of Operation 
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Previous Efforts 
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Bounded Asynchrony 
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S1A : function [period — ► bool] == (At: enough jclocks(t)) 
enough jciocks : function [period — ► bool = 

( A t : 3 * num^good jdocks(t, nrep) > a * nrep) 
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Clock Synchronization 
Verification and Implementation 


Paul Miner 

Systems Validation Methods Branch 
NASA Langley Research Center 
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Simulation of Algorithm Simulation of Algorithm 
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NASA’s Strategy for Technology Transfer 
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Systems Validation Methods Branch 
NASA Langley Research Center 


PRECEDING PAGE BLANK NOT FILMED 


107 



NASA’S STRATEGY FOR 
TECHNOLOGY TRANSFER 


by 

Sally C. Johnson 
NASA Langley Research Center 


GOAL 


Technology Transfer to Industry 


One of NASA’s major goals is to provide the U.S. aerospace indus- 
try with the tools and techniques they will need to be world-class 
competitors in the coming decades. 
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Technology Transfer 


KXISTINO 

FORMAL Mill' ‘HODS 
TOOLS ATLCIINIQUIiS 


INDUSTRY 

ni:i*:ds 



SYSTliM I AA 

I)I{sk;nl:rs 


FORMAL MHTIIOOS 
'STATH OFTIIIi PRAcnnr 


Working with Industry 


• Hoeing IMli hardware verification 

• Hoeing SVM hardware verification 

• (’SDL/OH A Scoreboard hardware verification 

• ORA Verification of Ada applicat ion software from NASA ( oxi- 
dat'd and Johnson 

- Formal specification and verilical ion of calendar utilities 

- Mode-control panel logic of Hoeing 7J7 experimental system 

specified in Larch 

• Currently pursuing future projects 
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Working with the FAA 


• Digital Systems Validation Handbook Chapter 

• Tutorial presentation to SWAT (SoftWare Advisory Team) 

• Formal specification of GCS application 

• RICA committee DO 17813 standard 
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Verification of FTPP Scoreboard 

and Spect.ool 

Mark Bickford 

Odyssey Research Associates, Inc. 


Ill 




112 


O 1 992 ORA Corporation 
SL-0041 



113 



The FTPP Logical Configuration 
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Abstract View of the Scoreboard 1 i; ( Actual Behavior 
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Controller state Machine 
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Proof of Msg Lemma: 
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Boeing’s Work in Formal Methods 


Dave Fur a 

The Boeing Company 


PRECEDING PAGE BLANK NOT FILMED 
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Space Transportation Systems Targeted systems: 

• Moon-Mars Initiative IH • tfTOS (Integrated Fault-Tolerant Avionics System^ 

e FTFP (Fautt-Tolerant Embedded Processor). 
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DO-178B and Formal Methods 


George Finelli 

Assistant Head, System Validation Methods Branch 
NASA Langley Research Center 


PRECEDING PAGE 8LANK MOT FILMED 
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DO-178B AND FORMAL METHODS 
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- Software Development 8 0 Software Quality Assurance Process 

- Software Verification 9 0 Certification Liaison Process 

- Quality Assurance and Configuration Management 10 0 /Upborne System 

1 1 .0 Software Life Cycle Data 

'J2J0 


s 
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Mechanical Prools 






Introduction to 

the Boyer-Moore Theorem Prover 

Warren Hunt 

Computational Logic, Inc. 


PRECEDING PAGE BLANK NOT FILMED 
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In general, a mathematical logic is defined by Infix Syntax 

• a formal language, (QUOTIENT (TIMES N (SUBl N) ) 2) 

• a set of axioms expressing assumed truths in the language, is printed as 
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(IMPLIES (PROPER-LIST? X) 
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The Output of REIFY 



then s 

else m(step(s), n-1) endif, 
for some ‘step' function. 
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Introduction to PVS 

Natarajan Shankar 

SRI International 
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Specification and Verification using PVS 


Outline 


N. Shankar 
sha nkar<3csl ,sri .com 


This talk is a short tutorial on specification and 
verification, using PVS as an illustrative example. 

• Background to PVS 


Computer Science Laboratory 
SRI International 


• Overview of PVS 

• Some Examples 
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Background; Past Experience 

Considerable accumulated experience on 
verification at SRI 

Systems developed at SRI include: Boyer-Moore 
Prover, HDM, OBJ, STP, EHDM, etc. 

Other Systems used include: Affirm, RRL, 
Gypsy, Muse, etc. 

Verifications include: Byzantine fault-tolerant 
clock synchronization, Byzantine Agreement, 
Godel’s first incompleteness theorem, and many 
others. 
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Background; EHDM 

Designed at SRI around 1984. 

A specification environment based on 
higher-order logic with parametric modules, 
implementation mappings, Hoare logic prover, 
etc. 

Theorem prover based on skolemization, manual 
instantiation, and Shostak's decision procedures. 

Example verifications include: Byzantine 
fault-tolerant clock synchronization, Ramsey 
theorem, Byzantine Agreement, Fault-masking 
and Transient recovery, etc. 
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Background: Lessons Learnt 


PVS 


Decision procedures are extremely useful but 
only a small part of what is needed. 

Highly automatic theorem provers are 
Inappropriate: difficult to control, and provide 
very little useful feedback. 

Low-level proof checkers are inefficient (both in 
machine and human terms), and also fail to yield 
a satisfactory proof. 

Logics with limited expressibility are easily 
mechanizable, but place a large burden on the 
specifier. 

Some highly expressive notations are nice for 
pencil-and-paper work, but might be difficult to 
adequately mechanize. 
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PVS: Overview 

PVS has been used to check proofs of 

• the Boyer-Moore majority algorithm 

• ordered binary tree Insertion 

• a version of the Schrttder- Bernstein theorem 

• Byzantine Agreement 

• a pipelined processor (due to Saxe), and 
other hardware examples. 

These proofs can typically be completed in less 
than a day. 


Started In mid-1990. 


The goal was to combine clear notation with a 
productive proof development environment to 
produce machine-checked, yet "humanly 
readable" proofs. 


PVS was primarily Influenced by EHDM, but also 
adapts ideas on language and inference from 
IMPLY, Boyer-Moore prover, LCF, HOL, ML, 
Nuprl, Veritas, OBJ, and many other systems. 


PVS consists of a core language definition, 
parser, typechecker, and proof checker. 

Contributors to PVS Include Sam Owre, John 
Rushby, Friedrich von Henke, David Cyrluk, Judy 
Crow, Carl Witty, and Steven Phillips. 
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Overview: Decision Procedures 

PVS proofs make heavy use of arithmetic 
decision procedures. Any theorem below Is 
automatically proved, conjectures are either 
false or unproved by decision procedures. 

arlthaatlc ; TMEORT 
BEG II 

x,y,x: TUI nu*b*r 
•ritfa: THEOREM 

x < 2*y AID y < 3*» IMPLIES 3*x < 18 *t 

badar ith : COIJECTURE 

x < 2*y AID y < 3*x IMPLIES 3*x < 17*t 

badar it h2 : COM JECTTJRE 

x<0 AID 7<0 IMPLIES x*y>0 

baddiv: COUECTURE 

(x/y) > x IMPLIES x > (y*x) 

f ooddix : CONJECTURE 

y/*0 AID (x/y) > x IMPLIES x > (y*x) 

inothiidiT: THEOREM 

y /• D AID (x/y) > (x/y) IMPLIES ((x-x)/y) > 0 

i, j, k: VAR int 
i star 1th : THEOREM 

2*i < 8 AID i > 1 IMPLIES 1 - 3 

badarithS: COMJECTURE 

2*x < 6 AID x > 1 IMPLIES x • 2 
EID arlthMtlc 
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Type Correctness Conditions 


Denominator for division must be non-zero. 
Typechecking the previous theory generates type 
correctness conditions. baddiv.TCCi is not 
provable, hence a type error. 

aritbMtlc: THEORY 
BEG IV 

x, j, v: VAR nubir 
arith: THEOREM 

i < 3 * j in r < 3 VT IMPLIES 3 * x < 10 • a 
badar 1th: COIJECTURE 

x < 2 * y ABD y < 3 • t IMPLIES 3 * x < 17 • t 

badar it h2 : COHJECTURE 

x < 0 AID y < 0 IMPLIES i * y > 0 

baddiv : COHJECTTOE 

<x / y) > t IMPLIES x > (y * t) . . . 

% Subtypa TCC gansratad far y 

baddlT.TCCl: OBLIGATI (Ml (FORALL (y: nnubar): y /- 0) 
gooddiv: CONJECTURE 

y /- 0 AMD <x / y) > ▼ IMPLIES x > (y • t) 
anothardia: THEOREM 

y /- 0 AID (x / y) > <t / y) IMPLIES ((x - t) / y) > 0 
1, j, h: VAR int 

intar ith: THEOREM 2 a i < 5 AID i > 1 IMPLIES i • 2 
badarithS: COIJECTITRE 2 * x < S AiB x > 1 IMPLIES x - 2 


EVD arithiaatie 
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Example: Binary Trees 

Binary trees can be defined as abstract 
datatypes. 

The following datatype declaration introduces 
the constructor leaf with recognizer leaf?, and 
constructor node with accessors vai, left, and 
right, and recognTz^nodeT. r ;= ~ 

Typechecking this datatype declaration 
generates the theories binary.tree.adt and 
binary-tree-rec-raod (shown below). 

blnary.traa [T t TYPE) : DATATYPE 
BECI* 

laaf : laaf? 

noda(val : T, laft : blnary.traa , right : blnary.traa) t noda? 

EVD blnary.traa 


Abstract datatype theory 

binary.traa.adt [T: TYPE]: THEORY 
BEGIV 

blnary.traa; TYPE 

laaf?, nodal: PRED [bin ary.tr aa] 

laaf: (laaf?) 

noda: [T, blnary.traa, blnary.traa -> (nod#?)] 

xal; ((nada?) -> T] _ __ . 

laft: ((noda?) -> blnary.traa] 

Tight: ((nada?) -> blnary.traa] 

laaf .axtanaionallty; AXIOM 

(FORALL (laaf?.xar: (laaf?)): laaf » laaf?.xaT) 

noda.axtanalonallty; AXIOM 
(FORALL (nada? .xar: (noda?)): 

nada(Tal(nada?.Tar) , l*f t(noda?_Tar) , Tight(nada?_xar)) 

* nada?. xar) — 

Tal.nodt: AXIOM 

(FORALL (nodal.Tar: T) , (nodal.Tar: blnary.traa) , 
(nodaS.Tar: blnary.traa): 

Tal(nada(nodal.Tar , noda2.rar, nad aS. T ar )) 

■ nodal.Tar) 

laft. nada: AXIOM 

(FORALL (nodal.Tar: T) , (nodal.Tar: blnary.traa) , 
(nadaS.Tar: blnary.traa): 

laft (noda(nodal_Tar , noda2.Tar, nadaS.Tar)) ■ nodal.Tar) 

right. nada: AXIOM j ^ 

(FORALL (nodal.Tar : T) , (nodal.Ta r : blnary.traa) , 

(nodaS.Tar: blnary.traa) 

rlght(noda(nodal.Tir, no dal.T ar , nodaS.Tar)) ■ nodaS.Tar) 


blnary.traa. disjoint : AXIOM 

(FORALL (binary.traa.Tar : blnary.traa) : 

ROT (laaf?(binaTy.traa.Tar) AID noda?(binary.traa.Tar))) 

binary .traa.lnclnaiTa: AXIOM 

(FORALL TbTnary.traa.Tar: blnary.traa) : 

laaf ?(binary.traa.Tar) OR noda 1 * (binary.traa.Tar)) 

binary .traa.lndoct Ion: AXIOM — 

(FORALL (p: PRED [blnary.traa] ) : 
pdaaf ) 

AVD . 

(FORALL (nodal.TaT: T), (nodal.Tar: blnary.traa), 
(nodaS.Tar: blnary.traa): 
p(nads2.Tar) AMD p(nodaS.Tar) 

IMPLIES p(noda (nodal.Tar, nodal.Tar, nodaS.Tar))) 
IMPLIES (FORALL (binary. traa. Tar : blnary.traa) f 
p(binary.traa.Tar))) 
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binary_troa_nat_rae( (lttfY.foa : ut) , 

(nodot.f on : [T, nat, nat -> nat!)): 
[binary.traa -> aat] * 

LAMBDA (binary .troa.rar: binary.traa) i 
CASES blnary.traa.rar Of 
laa 1: laai?.fun, 

nod* (nodal. rax, nodaS.rar, nodaS.var) : 
n oda?_f an (nodal. var, 

binary.tTOO.nat. roc (loaf ?_fun , 

nodo?_fon)(nodoS_Tar) , 
binary .traa_nat_rae(laalf .fan , 

nodo?_f on) (nodoS.rar) ) 

EIDCA9ES 

binary .troa.ordinal.roc((loaf?.f on: ordinal) , 

(noda?. fun: [T, ordinal, ordinal 
“> ordinall)): 

[binary.traa •> ordinal! » 

LAMBDA (binary.traa. tut: binary.traa) j 
CASES blnary.traa.Ttr Of 
loaf: laaf ?_fun, 

noda (nodal. rar, nodaS.vaT, nodaS.rar) : 
noda?_fun(nodal_rar, 

binary.traa.ordinal.rac(laaf?.lon, 

noda?. Ion) (nodal. rar) , 
binary.tran.ordinal.Tac (loaf?. Ion, 

noda?.fnn)(noda3_rar)) 

EIDCASE3 

EBB blnary.traa.adt 


Ordered Binary Trees 

obt [T : TYPE, <• : (total.ordar? [T!)! : THEORY 
BEG II 

U3I1W blnary.traa.adt , binary .traa.rac.aod 
A, B, C: TAB binary .traa(T) 
x, y, s: VAR T 
pp: VAR PREDCT! 

chock all((pp ; PRED[T]), A): bool - 
binary. traa.rac (TRUE, 

(LAMBDA x, (a, b : bool): 

(a AID b AID pp(x) ))) (A) 

1, k: VAR nat 
aixa(A) : nat ■ 

binary. traa.rac (0. (LAMBDA x, 1, j: 1 ♦ j ♦ 1))(A) 
ordaradt(A) : RECURSIVE bool - 

(IP noda? (A) TIE! (chackall ((LAMBDA y: y<-rol(A)), laft(A)) AID 
chackall ((LAMBDA y: raXAX-y), right(A)) AID 
ordarad?(laft(A)) AID ordarad?(rlght(A))) 

ELSE TRUE EIDIP) 

BT aira 

intart (x , A): RECURSIVE binary.traa [T! • 

(CASES A Of 

laaf: noda(i, laaf, laaf), 

noda(y , B, C): (IP *<«y THEM noda(y, lnaart(x, B), C) 

ELSE noda(y, S, lnaart(x, C)) 

EIDIP) 

EIDCASE3) 

BT (LAMBDA x, A: also (A)) 

ordarad?.lnaart.«tap: FORMULA 

pp(x) AID chackall (pp, A) IMPLIES 
chackall (pp, insarft(x, A)) 

ordarad?.lnaart : FORMULA 

ordarad?(A) IMPLIES ordarad?(lnaart(x , A)) 

EID obt 

13 


Recursion combinator 

binary. traa_rac.»od(T: TYPE, rang a : TYPE): THEORY 
BEG1I 

USIIG blnary.traa.adt (T! 

binary _t raa.Ta c ( (laaf T.fnn : rang a) , 

(nodat.f on : [T, Tanga, rang a -> Tanga])): 

[binary.traa -> rang a] ■ 

LAMBDA (binary .traa.rar: binary.traa) : 

CASES binary .traa.Tor OP 
laal: laal ’.Ion, 

noda (nodal. rar , nodaS.var, nodaS.rar) : 
noda?.fnn(nodal.var, 

blnary.traa.rac (laafT.fnn , noda?_fun) (nodaS.rar) , 
binary .traa.rac (laalT.lnn , noda?.fon) (nodaS.rar)) 

EIDCASES 

EID binary.traa_rac.Bod 


12 


Example Proof 

ordorodT.inaort : 

{1} (PORALL (a: T), (A: binary.traa) : 

ordarad?(A) IMPLIES ordarad?(lnaart(x , A))) 

Rula? (Induct "A") 

Inducting on A, 

this ylolda 7 aobgoala j 

ordaradt.inaart.l : 

I— 

(1) (PORALL (x: T) : ordarad?<laaf ) IMPLIES ordarad?(inaart(x , laaf))) 
Rnla? (skolemf) 

Pot tho top qoantlflor in 1, vo lntroduca Skolan conatanta: (xfS) 
thia ainplif iaa to: 
ordorodt.inaort . 1 : 

{1} oTda rad? (loaf) IMPLIES ordarad?(lnaart(x’S, laaf)) 

Rnla? (dsJmp) 

Applying dlajunetiaa simplification, 
this aiiaplifiaa to: 
ordaradT.lnaort . 1 : 

{-1} ordo rod? (laaf) 

| 

(1) ordarad?(lnsa T t(x'3, loaf)) 

Rnla? (rewrite "Insert") 

Ravriting naing inaart, 
thia simplifies to: 
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ordsrsd? -ins art . 1 : 


t-1] 

I 


ardarad?(lsaf) 


(1} 0rdarad?(noda(il3, l«*fi !••*)) 


Row? (rewrite "ordered?" 

Rsvritlng os inf ordsrsd?, 

this sinplifias to: 

0 Tdarad?-inaart . 1 : 

ord*rsd?(laaf) 


+) 


C-13 

111 (chschall((LAMBDA (y: 7) » T <“ *»*)» 

AID chsckalKaAMBDA <j: T) : x»3 <* y) , !••*> 
AID ordsrsd?(lsaf ) *« ordsr*4?(laaf 1 ) 


Ruls? (assert) 

Invoking dscision proesderas, 
this siMpllfiaa tot 
ordarsd?-insart .1 : 


[-1] ordsrsd? (laaf) 

| 

{1} chsckslK (LAMBDA (y: T): y <« 
AMD chsckslK (LAMBDA <y: T) 


*13) , lsaf ) 

: x ! 3 <- y). !••<) 


Uniat (auto- rewrite " blnary_tree_recfT . bool]" ) 

Installing automatic rsarltss: 
binary-traa_rsc [T , bool] , 

thla simp) ills* to: 

ordarsdt.insart .1 : 


(-1] ordsrsd? (loaf) 

Cl] chackalK (LAMBDA (y: T) : y <« x*3), loot) 

AID chackalK (LAMBDA <y: t) : *?3 <* y) , loot) 


Rais? (then (split )(rewrlte "checkall")) 
Splitting conjunctions, 
this yislda 2 subgoals: 
ordsrsd?_inssrt .1.1 : 

t-1] ordorad?(lsat) 

I 

(1} chackalK (LAMBDA <y: T): y <- x'3), l*af) 
Rsvritlng using chsckall, 

Thia complstss ths proof of ordsrsdT.inaart . 1 .1 . 

ordsrsd?. Insort .1.2 : 

t-1) ordsrsd? (lasf) 

, 

{1} chsckslK (LAMBDA (y: T): x»3 <- y) , lsaf) 
Rsvritlng using chsckall, 

Thia coaplatsa ths proof of ordsrsd?_inasrt . I . 2 . 


This coaplatas tha proof of ordsTodf-ipaort .1 . 


ordsrsd?. inaart .2 : 

{1} (FORA LI (nodal-var : T), (nods2.v*r: binary-tTss) , 

(nodaS.var : binary Jtras) : 

(FORALL (x: T>: - ... 

ordsrsd? (nods2.var) IMPLIES ordsrsd?(inasrt (x , nods2.var))) 

AID 

(FORALL (x: ?): 

ardor ad? (nod* S.var) 

IMPLIES ordsrsd?(inssrt(x, nodsS.var))) 

IMPLIES 

(FORALL (x; T): 

ordsrsd?(nods(nodsi-sar, nods2_var , nodaS-rar)) 

IMPLIES ordsrsd?(inasrt(x , nods(nodsl.var , 
nod o2 -sot, 
nods3_var))))) 


Rnls? (dslmp) 

Applying di#junetiva simplification, 
thia aiaplifisa to : _ 
ordsrsd?. inasrt. 2 : 

(-1) (FORALL (si T): 

ordsrsd? (nods 2 _ vst ! B) 

IMPLIES ordsrsd? (inasrt (x , nods2-rar ?6)>) 

{-2} (FORALL <x: T)i , = ^ 

ordsrsd? (nodsS.Tar IS) 

IMPLIES ordsrsd?(inasrt (x, nodsS. vor IS) )) 

{1} (FORALL (a: T) : 

ordsrsd?(nods(nodsl.rar !4 , nods2-»at!B, nods3-var!B)) 
IMPLIES ordsrsd?(inasrt(i, nods (nods l.var! 4, 
noda2-vnrl5, 
nods3.Tar 16)))) 


Rais? (skolem!) 

For ths top qnantlf isr in 1, *s introduc* Skolsa constants: 

(nodsl.sarM nods2.vaTl5 nods3_var!8) 

thia aiaplifisa to: 
ordsrsd?-inasrt .2 s 


a) (FORALL (x: T): 

ordsrsd? (nods2.var ! B) IMPLIES ordsrsd?(inssrt(x, nod*2.var IS))) 
AID 

(FORALL (x: T): 

ordsrsd?(nods3_rar ?S) •— — 

IMPLIES ordsrsd?(inssrt(x, nods3_Tar !•))) 

IMPLIES 

(FORALL (x : T) : 

ordsrsd? (nods (nodal _rar * 4 , nods2_raT»B, nods3_var*B)) 

IMPLIES oTdar ad? ( inasrt (x, nods(nodsl.var *4 , 
nods2.var*B, 
nods3.rar!S)))) 


Rols? (skolem!) :i .L— . 

For ths top quantifisr in l,vp introduc* Skolsn constants: (x'7) 
this slaplifiss Vo~: '^3=7 =7s-i:: 

0Tdarad?.insart.2 : — 


E-l] 

t-2) 

I — 


(FORALL (x: T): 

ordsrsd? ( nods?- var 1 6) • 

IMPLIES QTdsrsd?( inasrt (x, nods2.var •&))) 

(FORALL (x£ j)j 1 1 2 . ! •- " r ■; 

ordsrsd? (nods 3.rar IS) 

IMPLIES ordarad?( inasrt (x, nods3_var 16))) 


ordsrsd? (nods(nodsi_Tsr 14, nods2.rar'5, no4s3.r«!«)) . 
IMPLIES ordsrsd?(inssrt(x*7, nods(nodsl-?ar*4, 
nods2-varl6, 
nods3_var!8)]) 
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Rnlat (rewrite "ordered?** +) 

Ravriting nalng ordaradt, 
thin ainplif laa to: 
ordaradt.lnaart .2 i 

[-13 (FORALL (a: 7) i 

ordaradt(n©da2.vax16) 

IMPLIES ordaradt ( in aart(x, nodaS.var 16))) 

[-2] (FOR ALL (as 7): 

ordaradt (nodaS.var (6) 

IMPLIES ordaradt(iaaart(x, nodaS.var! 6))) 

{1} (chackall ((LAMBDA <y: 7): y <« nodal.var!!) . n©dn3-var!6) 

AID chackall ((LAMBDA (y: T) : nodal.var!! <• y), nodaS.var! 8) 
AID ordaradt (noda2-var! 6) AID ordnradT(nodaS_var!6)) 
IMPLIES ordarad?(inaaTt(a !7 , noda( nodal.var 14, 

Mdal.varlli 
nodaS.var! 6))) 

Rnlat (dnlmp) 

Applying diajnnetiva ainplification, 
thia aiMpllfiaa to: 
ordaradt.lnaart ,2 t 

[-11 (FORALL (a: 7): 

ordaradt (nodaS.var ! 8) 

IMPLIES ordaradtdnaart (a , nodaS.var 16))) 

[-23 (FORALL (a: 7): 

ordaradt(noda3_Yar *6) 

IMPLIES ordaradtdnaart (a, nodaS.var ! 6))) 

4-3) chackall ((LAMBDA (y: T): y <- nodal.var!!) . noda2-vaT!6) 

(-4) ehackalK (LAMBDA (y: 7): nodal.var!! <- y), noda3.var!6) 

{-8) ordaTadT(noda2-vor! 6) 

(-«} ordaradt (nodaS.var ! 6) 

| 

{1} ordaradtdnaart (a !7 , noda(nodal.var!4, 

noda2-vnr !B , 
nodaS.var!®))) 


Ralat (rewrite "Insert" +) 

Ravriting nalng inaart, 
thia slnpliflas to: 
ordarodt-lnaort .2 : 

[-13 (FORALL (a: 7): 

ordoradt (nodaS.var ! 8) 

IMPLIES ordaradtdnaart (a, nodaS.var! 8))) 

[-23 (FORALL (a: 7): 

ordaT ad t( nodaS.var 1 6) 

IMPLIES ordaradtdnaart (a , nodaS.var! 6))) 

[-33 chackall ((LAMBDA <y: 7) : y <» nodal.var!!), noda2-vor!6) 

[-43 ehackalK (LAMBDA <yt 7): nodal.var?! <- y) , nodaS.var!®) 

[-83 oTdarad? (nodaS.var !8) 

[-8) ordaradt (nodaS.var 1 8) 

(1) ordaradt((IF a!7 <■ nodal.var!! 

THE! 

noda (nodal.var 14, 

la*art(x!7, noda2_vor ! 6) , 
nodaS.var 16) 

ELSE 

noda (nodal.var 14, 
noda2.var 16, 

lnaart(x!7, nodaS.var !8)) 

EIDIF)) 

Ralat (lift- If) 

Lifting IF-condltlona to tha top laval, 
thia ainpllflaa to: 


OTdaradT.inaart .2 : 

[-13 (FORALL (n 7): 

OTdaradt (nodaS.var! 6) 

IMPLIES ordaradt(lnaaTt(a p nodaS.var! 6))) 

[-23 (FORALL (a: 7): 

ardaradt (nodaS.var 18) 

IMPLIES ordaradt(inaart(x, nodaS.var 18)3) 

[-33 ehackalK (LAMBDA (y: 7): y <- nodal.var!!) , noda2-Yor!8) 

[-43 chackall ((LAMBDA (y: 7): nodal.var!! <- y), noda3.var!6) 

[-83 ordaradt (noda2-Yar 18) 

[-63 ordaradt (nodaS-var! 8) 

(1} IF *17 <• nodal.Yar!4 . . . . 

thoi 

ordaradt (noda (nodal.Yar 14, 

lnaart(x!7, nodaS.varlB) , 
nodaS.var! 6)) 

ELSE 

ordaradt (noda (nodal _vaT 1 4 , 
noda2.var !8, 

lntart(x!7, nodaS.var! 6))) 

EIDIF 

Rnlat (propS) 

By propositional slvplif ication, 
thia yialda 2 sobgoals; 


ordaradt.lnaart .2 . 1 t 




t-23 


[-S3 


[-43 

[-63 

[-83 

(-73 

I- 

<l) 


r !7 <* nodal.Yar t4 
(FORALL (*:?): 

ordaradt (noda2.vaT 18) 

IMPLIES ordaradt(insart(x, noda3.var 16))) 

(FORALL (*i 7): 

ordaradt(aodaS_var ! 6) 

IMPLIES ordaradt (inaart(x, nodaS.var !6))) 
ehackalK (LAMBDA (y: T) : y <- nodal.Yar 14), n©da2_var!6) 
ehackalK (LAMBDA (y: 7): nodal.var! 4 <• y), nodaS.var 16) 
ordaradt (nod a2.var 1 6) 
ordaradt (nodaS.var 1 6) 

OTdaradt (noda (nodal.Yar 14 , inaart(x!7, nodaS.var! 6) , nodaS.var !8)) 


Rnlat (rewrite "ordered?" +) 
Ravriting oaing ordaradt, 
thia ainpliflas to: 
ordaradt.inaart.2.1 : 


[-1] *!7 <■ nodal.var (4 

[-23 (FORALL (*: T): 

ordar ad t (nodaS.var 1 6) 

IMPLIES ordaradt(inaart(x, nodaS.var 1 8))) 

[-33 (FORALL (x: 7): 

ordaradt (nodaS.var 1 8) 

IMPLIES ordaradt ( laaart (x , nodaS.var 16))) 

[-43 ehackalK (LAMBDA (y: 7): y <- nodal.var 14) , noda2vnr!6) 

[-83 ehackalK (LAMBDA (y: 7): nodal.var!4 <- y) , nodaS.var!®) 

[-63 ordaradt (nodaS.var 18) 

[-73 ordaradt (nodaS.var 16) 

(1) (ehackalK (LAMBDA (y: T)i y <• nodal.var 14) , 
lnaart(x!7, nodaS.var 18) ) 

AID ehackalK (LAMBDA (y: T): nodal.var!! <» y), nodaS.var '«) 
AID ordaradt(inaart(x!7, nodaS.var 18)) 

AID ordaradt(noda3.var 16)) 
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ordor odt_ lns«rt .2. 1 : 


Rulot (quant?) 

Found substitution: 
x got* x!7 p 

Instant luting quantifiod tiiIaUm, 
this aiuplifioa to: 
ordorodt. Insort .2.1 : 

[-1] *17 <■ nodol-aar! 4 

{-2} ordorod? (nodo2_aar ! S) IMPLIES ordorodt(insort(*‘7 p nodo?_aar »6)) 
t-3] (FORALL <*: T) : 

ordorod? (aodo3-aur 10) 

IMPLIES ordoTod? ( inaort (* , aodnS^wfS) )) 

[-4] chockall ((LAMBDA (y: 7): y <• nodol_aar!4) , nodo2.aar!6) 

[-6] chockalK (LAMBDA (y: 7): nodol.aarlA <- y) , nodo3-aur«0) 

(-«) OTdoTodt (nodo2_uar f 6) 

(-7] oTdorod?(nodo3..aur10) 

[ij (chockall ((LAMBDA (y: 7) t y <- nodol.aar 1 4) p 
insort(x17, nodo2-aar 15)) 

AID chockulK (LAMBDA (y: 7): nodol-aar! 4 <• y). nodo3-aar!6) 
AID ordorod?( insort (* >7, nodo2~aar » B)) 

AID ordorodt (nodo3_aar 10)) 

Rulot (props) 

By propositional si*plif ication P 
thio ainplifios to: 


{•1} ordorod? (iosort(x!7, nedo2.aar IB)) 

[-2] *17 <• nodol-aar 14 

C-3] (FORALL (*: 7): 

ordor ad? (nodoS.aar I 6) 

IMPLIES ordorod?( inaort (x , nodo3-tar!0))) 

C-4) chockalK (LAMBDA (y: 7); y <- nodol.aar 14) , nodo2_aar IB) 

[-6] chockalK (LAMBDA (y: 7): ncdol-tnr!4 <« y). nodoS.aar !fl) 

[-•) ordorod? (nodo2_anr 16) 

(-7) ordorodt (nodoS.aar 10) 

{1} chockalK (LAMBDA (y: 7): y <- nodol-aar14) , 
inaort(xf7, nodo2-oar IS)) 


Rulot (rewrite H ordered? Jnsert-Step") 

Rovriting uaing ordoTod?. inaort_atop , - 

7hia coaplotoa tho proof of ©rdoTodt.inoort .2. 1 . 

ordorodt. Insort .2.2 : 

[-1] (FORALL (*:?): 

ordorod?(nodo2-aar 1 6) 

IMPLIES ordorod?(inaort(x p nodo2.aar 16)) ) 

[-2] (FORALL (*: 7): 

ordorod? (nodo3-anr I 6) 

IMPLIES ordo rodt(inaort(x, nodo3.aar *6))) ~ y 

[-3] chockall ((LAMBDA (y: 7): y <* nodal -aar *4) , nodo2-aar!B) 

C-4] chockall ((LAMBDA (y: 7): nodol.aar 1 4 <- y), nodoS.aar *6) 

(-&] ordorod? (n©do2-aar IB) 

t-0] ordorod? (nodoS.aar 10) _ 

{1} x!7 <• nodoi.u arii - . 

■{2} ordorod? (nodoTnodoI-aar 14, 

nod©2_aar!5 f «*i- 
inaort(x!7 p nodoS.aar 10))) 


Rulot (rewrite w ordered? w +) 

Roar i ting uaing ordarodt, 
thia oioplifioo to: 
ordarodt.insort .2.2 : 

(-1) (FORALL (*: 7): 

ordoTod? (nod*2-aar I 6) 

IMPLIES ordor odt( inaort (x p nodoS.aar IS))) 

C-2] (FORALL (x: 7): 

ordorod? (nodoS.aar 10) 

IMPLIES ordorod?(inaort(x f nodoS.aar 10))) 

C-3] chockall ((LAMBDA (y: 7): y <• nodul-aar»4) , nodo2_aaTl6) 

[-4] chockall ((LAMBDA (y: 7): nodol.aar 14 <- y), nodoS.aar 10) 

[-6] ordorod? (nodoS.aar IS) 
t-B] ordorod? (nod aS.anr !0) 

| 

El) x!7 <• nodol.varM 

(2} (chockall ((LAMBDA (y: 7): y <■ nodol.anrid) , nodo2-aar!6) 
AID 

chockalK (LAMBDA (y: 7): nodol_aar!4 <• y). 
inaort(x!7 p nodtS.rar 16)) 

AID ordorod?(nodo2_aarf 6) 

AID ordor ©d? (Inaort Cm ! 7, nodoS.aar I 0))) 

Rulot (quant? -2) 

Found substitution: 
x goto x!7. 

Instantiating quant if iod variabloo. 
this sinplifios to: 


ordorodt.insort .2.2 ; 

C-i) (FORALL (*: 7): 

ordorod ?(noda3.aar I B) 

IMPLIES ordorod t( insort (x, nodoS.aar IB))) 

(-2) ordorodt (nod a3. aar 10) IMPLIES ordorod?(inoort(xl7 , nodo3.var 10)) 

[-3] chockall ((LAMBDA (y: 7) : y <- nodol-aar 14), nodo2-aur»B) 

[-4] chockall ((LAMBDA (y: 7): nodol.aar 14 <« y), nodo3.aar*0) 

C-6] ordorodt (nod a 2 .aar IS) 

[-6] ordorod? (nodoS.aar I 6) 

| 

[1] x!7 <• nod©l-aar!4 

[2] (chockall ((LAMBDA (y: 7) : y <- nodol-aarM) , nodoS.aar IS) 

AID _ __ ' * “ 

cho ck d l( (LAMBDA (y: 7): nodol .aar!* <« y) , _ 

insort (x 17, nodo3.var 10) ) 

AID ordorodt(nodo2.rar IS) 

AID ordorodt(lnsort(x!7, nodoS.Tar 16))) 

Rulot (propS) 

By propositional aiioplificatlon, 
this aiiqpllfios to: _ 

ordorodt.inaort .2.2 : — - ■ 

{-1} ordorodt(inoort(*l7, nodoS^aar 16)) 

(-2) (FORALL (*: 7): 

o r dor od t ( nodo2-aar_! B)_ 

IMPLIES ordorodt (inaort (x, nodo2.aar *B))) 

C-3] chockall ((LAMBDA (y: 7) : y <■ nodol-aar 14) , nodo2-aarl6) 

C-4] chockall ((LAMBDA (y: 7): nodol-aar 14 <• y) , nodoS -aar?6) 

t-6] ordo rodt (nodo2-aar f 8) 

[-6] ordorodt (nodoS-aar 10) 


(1} chockalK (LAMBDA (y: 7): nodoi.aar‘4 <- y) P 
insort(*l7, nodo3.aar!0)) 

[2] *17 <• nodol-aar 14 
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mu ii n 


Rule? (rewrite M ordered? Jntert-Step H ) 

Rewriting eslng ordsrsdT-insert-stsp. 
this simplifies to i 
ordered? .insert .2.3 : 

[-1] ordered? (Insert(xt7, aodeS.Tirlt)) 

[-31 (FORALL (x: 7): 

ordered? (node3_Ter ! 6) 

IMPLIES ordered? ( insert (x, node2-wer ! 6) ) ) 

[-3] eheckelK (LAMBDA (y: T)r y <• nodel.TerU) . nodeS.Ter I 6) 

[-4] eheckelK (LAMBDA (y: T): nodei-TOTU <- y), nodeS.TerU) 

[-5] ordered? (node2.Ter 16) 

[-6] ordered? (nodeS.Ter 10) 

| 

\i) nodel.TerU <• *!7 

[31 eheckelK (LAMBDA (y: T) : nodel.TerU <- y), 
insert (* !7 , eodeS-Ter 10)) 

[31 x 1 7 <* nodel.TerU 

Rale? (typepred *obt.<-") 

Adding type conetrnlnts for obt.<«, 
this simplifies to: 
ordered?. insert .3.3 : 

(-1) tetel-order?m (obt .<■) 

[-31 ordered?(lnsert(x !7, sodeS.TsrtO)) 

[-31 (FORALL <x: 7): 

order ed?{ nodeS.Ter ! 5) 

IMPLIES ordered? ( insert (*, node3.eer * 6))) 

[-41 eheckelK (LAMBDA (y: T): y <■ nodei.TurU), nodeS.Ter 16) 

[-61 eheckelK (LAMBDA (y: T): nodel.TerU <■ y), nodoS.Ter 16) 

[-6} ordered? (nodeS-ver! 6) 

[-7] ordered? (nodeS.Ter 10) 

| 

[ll nodel.TerU <* *!7 

[31 eheckelK (LAMBDA (y: t) t nodel.TerU <• y), 
insert (x 17, nodoS.Ter 10)) 

[3} x(7 <■ nodel.TerU 


ordered?. insert .3.3 : 

(-1) nodel.TerU <« *17 OR *17 <« nodel.TerU 
[-3} ordered? (lnseTt(x1 7, node3_rerf 6)) 

[-31 (FORALL (x» T): 

ordered? (node2.Ter 16) 

IMPLIES ordered? ( insert (x, node3_ver 1 6))) 

[-41 eheckelK (LAMBDA (y: 7): y <» nodel.TerU) , node3-ver!6) 

[-6] eheckelK (LAMBDA (y: ?): nodel.TerU <« y), nodeS.TerU) 

[-6] ordered? (noded.ver 1 6) 

[-71 ordered? (node3.rer 10) 

| 

[ll nodel.TerU <■ *17 

[31 eheckelK (LAMBDA (y: t) : nodel.TerU <* y). 

Insert (x 17 « nodeS-ver 10)) 

[31 *17 <■ nodel-xerU 

Rale? (prop$) 

By proposltlonel slnpll 71 cation. 

This complete* the proof of order ed?.insert .3.3. 


This completes the proof of orderod?.inoert .3 . 

Q.E.D. 

Sere the nee proof? (Yss or Bo) yes 

tfoeld yon like e bTief prlntoat of the pToof? (Yes or Bo) yes 
ordered?. insert : 

{1} (FORALL (x: T) , (A: binery.tree) : 

ordered?(A) IMPLIES ordered? (Insert (x , A))) 

Indactlng on A. 

which yields 3 sabgoels : 


Rale? (rewrite "toUl^order?") 

Rewriting xsing totel.order?, 
this simplifies to: 
ordered?. insert .3.3 : 

{-1} FORALL (x, y: T): * <■ y 0* y <■ x 
[-2J ordeTed?(insert(x1? # nsde3.ver !•)) 

[-31 (FORALL (x: T): 

order ed?(nod«3.Ter 1 6) 

IMPLIES ordered? ( insert (x, nodel.Ter 16))) 

[-4] eheckelK (LAMBDA (y: T): y <- nodel.TerU), node3.Ter)6) 

[-61 checkell (( LAMBDA (y: T) : nodel.TerU <» y), nodeS.TerU) 

[-•) ordered? (node3.Ter 16) 

[-7) ordered? (nodeS.Ter 16) 

[ll nodel.TerU <■ xl7 

[3] eheckelK (LAMBDA (y: T) : nodel.TerU <- y), 
insert (x 1? , nodeS.Ter !•)) 

[31 x!7 <• nodel.TerU 

Rale? (quant?) 

Foond substitution: 
y gets *17, 
x gets nodel.TerU, 

Instent let ing quantified Terlebles, 
this sinplifies to: 


ordered?-insert . 1 i 
| 

(1) (FORALL (x: 7): ordered? (leaf) IMPLIES ordered? (insert (x, leef))) 

For the top quantifier in 1, we introduce Skolen constants: (x!3) 
Applying disjunctiTS eimpllf lent ion, 

Ren-lting using inesrt. 

Rewriting using ordered?, 

Inwoklng decision procedures. 

Installing automatic rewrites: 
binary. t re e.rtc [7 , bool] , 

Splitting conjunctions, 
which yields 3 sabgoels: 

ordered?. Ins art .1.1 : 

(-I) ordered? (lssf) 

{1} eheckelK (LAMBDA (y: T): y <■ it)), leef) 

Rewriting using checkell. 

This completes the preef sf ordered? .insert . 1.1 . 
ordored?.lneort.l .3 : 

(-1} ordered? (leef) 

(1) eheckelK (LAMBDA (y: 7): x?S <• y), leef) 

Rewriting using checkell. 

This collates the proof of ordered*. insert .i.2. 
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ordered?. insert .2 t 


I 

{1} CFOMLL (nodel _v«: 7), (nod*3.Ter: Mnniy-tT m), 

(nod* 3. Tar : binary .tree) : 

(FORALL (*: 7): 

ordered? (nod* 2-ver) IMPLIES erd*rwd?(inswrt (a , nodel-ver))) 

m 

(FORALL (*: 7): 

ordered ?<nod*3_v*r) 

IMPLIES ord*r*d7(in**rt(*. n*d*S-v*r))) 

IMPLIES 

(FORALL (x: 7 )t 

ord*r*d?(nod*(nod*i_T*r , nod*2_vwr, nod*3_v*r)) 

IMPLIES 

ord*r*d?(ins*rt(x , nod*(nod*i-T*r , 
nod*2-vsr, 
nodsB-vur))))) 

For the top quantifier In 1, w* ia troduce_gfcq l«i co nstants: 

(nodel ..vnT !4 nod*2-Tar!B rod* 3 .war !•)' 

Applying disjunctive simplification. 

For th* top quant if i«T in 1, *• introduce Skolem constants: (x!7) 
Rewriting using ordered?. 

Applying disjunctive simplification. 

Rewriting using insert, 

Lifting IF-conditions to th* top 1«t*1, 

By propositional simplification, 

which y laid a 2 subgoals: 


ordered?. insert .2.2 : 

{-1} (FORALL (*: 7): 

order *d?(nod*2_var f B) 

IMPLIES ordered? (insert (x * nod*2_v*r»6))) 

{ -2)* (FORALL (x: Y)i ' t==r±==lf“-- - : ^ “ r ” - : 

ordered? (node S.var 1 6) 

IMPLIES ordered? ( insert (x, nod*3_Ter!6)l) ^; = .i 

{-3} checkall ((LAMBDA (y: 7): y <• nodal-varU) , nod*2-sar*B) 

{-4} chsckall ((LAMBDA (y: 7): uod*i_var!4 <- y*7 nod*3.var!«5 

{-$} ord ere d? (nodoS-Tor ! $3 
{-6} ordered? (nodeS.var IB) 

{1} x!7 <■ nod*l-var!4 

{2} crd#red?(nod*(nod*l-varM, 

nod*2-var J B , 

insertCx!?, nod*3_var!B))) 

11* writing uaing ordered?, 

Instantiating quantified variables, 

By propositional simplification , 

Bowriting using ord*r*d7 -lns *rt-at*p , . ... 

Adding typo const ra ints for obt.<», 

Rewriting using total-order? , 

Instantiating quantified Tariabl**, 

By propositional simplification, 

This completes the proof of ord*r*d?_ins*rt .2.2. 


Q.E.D. 


ordered?, insert .2. 1 j 

{-1} *17 <• node I .tot 1 4 

{-2} (FORALL Tx: 7): r 

ordered? (no do 2-Tar ! S) 

IMPLIES ordered? (in sort (x , nod*2-T*r »B))> 

{-3} (FORALL (x: 7): 

ordered? (nod* 3-war ! 6) 

IMPLIES ordered? (insert (x , nodeS-ear !«))) 

{-4} checkall ((LAMBDA (y: 7): y <* nodei.war !4) , nod*2.var'B) 

{-6} checkall ((LAMBDA (y: 7): nod*l.war!4 <■ y). nod*S_v*r!B) 

j-8) ordered? (rodeS.vor ?6) 

(•7} ordered? (nodeS. war !4) 

{1} order ed? (node (nodei-war !4, 

in*ert(x?7, nod*2.ver!S) , 
node 3-war IB)) 

Rewriting using ordered?. 

Instantiating quantified variables, 

By propositional simplification. 

Rewriting using ordered?. insert.atop, 

This completes the proof of ord*T#d?.ins*rt .2.1- - 


Notes on the Language 


The core logic Is a simply typed higher-order 
logic. 

Spe cificatio ns are structured into par amet ric 
theories. " 

Types can be parameters. 

Assumptions can be used to constrain the 
parameters. 


Set-like predicate subtypes can be defined. 
These make the domains and ranges of 
operations explicit. 


Theorem proving is employed to carry out 
typechecking. .. 


Automatic facilitiy for generating abstract 
datatype theories. - 
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Conclusions 


Notes on the Proof checker 

Sequent representation for proof goals. 

Backwards proof construction by applying 
reductions. 

Heavy use of powerful decision procedures for 
equality and inequality. 

Powerful primitive inference steps. 

Roughly twenty such steps. 

Strategy mechanism for encapsulating proof 
patterns. 

Ability to save and rerun proofs and partial 
proofs, and display proofs. 


PVS exploits the synergy between language and 
Inference. 

The combination of powerful inference steps: 
decision procedures, rewriting, propositional 
simplification, etc., makes it effective to develop 
proofs that are both certified and convincing. 

Future goals: 

• To enhance the language to further exploit 
the inference capabilities 

• To generate readable proof outlines 

• To make proofs robust and easier to 
maintain 
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Logical Foundations of Computing 
over the Floating Point Reals 

Richard Platek 

Odyssey Research Associates, Inc. 
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Logical Foundations of 
Computations over the Reals 


Richard Platek 

Odyssey Research Associates 
ORA 

12 August 1992 
NASA FM Workshop 


©ORACorp, 1992 
SL-0046 
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Basic Problem 

What does it mean to say that a given program "computes" a real valued 
function such as sine x or e* when it never really does? 

Classical answer: 

The program computes an approximation which is "sufficiently accurate" 
But what does that mean? 


© ORA Corp, 1992 
SL-0046 
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Two Fundamental Problem Areas 


□ Scientific Computations 

simulations, cacluation of engineering solutions, numerical experiments to 
explore theories, "number crunching" as part of experiments 

correctness is vital for decision making 

□ Embedded Computations 
computers as part of coninuous systems 

sense-compute-activate 




Botton Up Interpretation 

We reason at the level of the CPU and Floating Point processor so that we can 
calculate tight error bounds and we use numerical analysis techniques to 
estimate the accuracy of the computation. 

Perfectly fine, but too concrete 

A. Numerical Programs are not written in machine language or assembler. 
They are written in higher order languages like Fortran, C, Ada. The 
concrete analysis is not portable across CPU’s. 

B. The concrete analysis is not portable across FPP’s. We should reason in 
terms of the IEEE floating point standard or the Brown model. 

In particular, our specs and proofs should be independent of the word length of 
the machine reals except in so far as the word length is knowable at the 
programming language level (e.g., Ada's float'small) 


©ORACorp, 1992 
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Verifying floating point computations 

n Algebraic properties of floating point operations are a mess; and detailed 
descriptions are highly implementation dependent. 

□ Little automated support exists. 

□ We are incorporating support for both quantitative and qualitative error 
analysis into Penelope. 

This talk concerns qualitative error analysis. 


©ORA Corp, 1992 
SL-0046 
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Example of Compiler Implementation Strategies 


In both C and Ada the statements 

X : = y * z ; 

if x = y * z then w 

w 

may set w to either 0 or l !!! 


= 0 else 
:= 1 end; 



CORACorp, 1992 
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Qualitative analysis of roundoff error: asymptotic 

correctness 

Mathematical model via limits 

If a program is run on increasingly accurate machines, then its answer 
approaches the specified result in the limit. 


Mathematical model via algebra 

Use a model of "approximate reasoning. 
The algebraic model is easier to use 


©ORA Corp, 1992 
SL*0046 
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Algebra for approximate reasoning 


Introduce additional predicates on the "real 
numbers" 

x & y x is close to y 
x 9 by x is not close to y 
x < y x < y or x is close to y 
x <£ y x <y and x is not close to y 

Relations to standard operations 



x = y =► x ~ y 


£y^x<y=>x<y^x<y 


©ORACorp, 1992 
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Modeling Ada floating point operations 

Introduce specification predicate for each basic operation 

fplus(x,y,z): 

z is a possible result of evaluating x * y 

Sample property: 

fplus(x , y, z) => z w z + y 


fle(x,y,b): 

6 is a possible result of evaluating x <= y 


Sample properties: 

fle(x,y,truc) => x < ;/ 
f/e(x, y, false) => x > y 


© ORA Corp, 1992 
SL-0046 
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Code for mysqrt 

function mysqrt (...) is 
x : float; 

begin 

if (a <= small) then 
return 0.0; 
end if; 
x : ** a + 1.0; 

while (x*x-a >= small) loop 
x : = ( x+ (a/x) ) / 2 . 0; 
end loop; 
return x; 
end mysqrt; 

Loop invariant annotation: 

small, x, a, (x 2 — a) ^ 0.0 



171 




f 172 


im in i mu mm nut . i :i i u imi him niiiiw 


1 

Embedded Systems 

Want to be able to reason about computer controlled real world systems. 

Want to know what the system does in real space/time. 

The total syste can be described by logico-differential equations. 


V 
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Example 




State variables 


x ( t : Real ) : Real 

y (k : Int ) : Int 


Transition Relations 


cl£ = f (x(t), y(L)) 
y (k + 1) = g (x(l) , y (k) ) 


itj = max integer < t 


©ORA Corp, 1992 
SL-0046 
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Formal Safety Analysis 

Nancy Leveson 

University of California at Irvine 
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Verification 
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To produce a verifiable and certifiable design. 
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Compuur 




181 


• Fijura 4d 

low- risk S141C Reachability Graph for Fi*ura 4c 
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Approaches to finding errors in requirements GENERAL APPROACH: 
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Validation on & realistic testbed 
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Low = v(I) < C*K 
HifK = V (I) > C*K 
TimeOvt(x) = t > *(xT) + 3Q 
Out(0,Z ) a OTA(w(0)«*) 








Criterion 6.1 Every state must have a behavior (transition) defined for 
every possible input. Formally, 
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Criterion 9.4 There must be no paths to undesired 
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Figure 1.1: Component Communication 
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Other- Aircraft ft] 
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b« within 1200 ft, r * 0 xAj. If the intruder is not altitude reporting, then it considered proxhnat xf A .... Q - .... . * . , ^ 

traffic only if own altitude is below 15500 ft< **>***<:, and the bcarine and ranee reoort* ar Wot€: ,f A «-R» t ®- p ^*-RA*^n[ | ] is not defined for Other- Aircraft* 7 r(i), then do not consider 

considered valid. * into lhc **><>ve. Al *> «*• ** positive RA’s are in the same diction. 

Reference: MOPS: Determine-goal-rate (p. 389). 

MOPS Reft TRAFFIC-ADVISORY. Proximity Jtest. 
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The FM9001 


Warren Hunt 

Computational Logic, Inc. 
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The FM9001 Architecture 
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The FM9001 Pinout An FM9001 Factorial Program 
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A Circuit with Trl-state and Latches Trl-state Circuits with Latches 
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ALU Generator Output Summary The FM9001 Netllst 
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Testing the FM9001 Undetectable FM9001 Faults 
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Derivational Techniques for Hardware 


Steve Johnson 

Indiana University 
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Deduction and Derivation... 


o have a lot in common 
o reflect common modes of reasoning 
o involve "proof engineering" 
o should be integrated 
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Digital Design Derivation system 
(DDD) 

• An interactive transformation system based on 
first-order* functional expressions 

• Specialized for digital system derivation 


DDD as a formal system 


• A core of secure algebra 
o Extensibility 
o Derivation management 



Modes of expression 
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define (SO In Out) - 
(if (- 0 (? In)) 

(SO (> In) 0 0 Out)) 
(Si (> In) (f 0 Out))) 

s 

define (SI In Out) • 

(if (- 0 (? In)) 

(SO (> In) (! 1 Out)) 
(SI (> In) ( ! 0 Out))) 


Behavior to structure: 


define (FAC n) ■ (F n 1) 
where 

(F u v) • (if (zero? u) 

▼ 

(F (dcr u) (mpy u v))) 


define (FACsystea n) * (list V R) 
where 

U » (coni n (DCR U)) 

V - (coni 1 (KPY U V)) 

R - (ZERO? U) 











FM8501 implementation [Hunt] 

(4af* IIB-UC1IIK (Mr raa4 writ* itid mrt M-atara 

r«|~f li« iMr-m c-flag *-fl«g i-fl*! 

a-rag V-r«{ I>t«| 

•aaorj -aat cl -J«g~fc III ory aracla) 

(if (allatp tficlt) 

(Hat mt mi arita itack raaat aa-atara iiti-Mt rtj-fiu 
aMr-aat c-flag a-flag i-flag a-flag t-rag k-rag i-r»| 
▼laaal-Ma raal-aaa aBaarj-aatek-Bag-klatory) 

(aia-HAClin (Mr Mr I-rag Had raaat 
(raa4 aar 1-rag) 

(arita aar 1-rag ae-axera) 

(4«ack (car aracla)) 

(raaat (car aracla)) 

(aa-atara aa-atara c-flag r-flag a-flag a-flag 
i-rag aar) 

(4tta-aat iatt-ait a -rag k-rag c-flag l'rag aar) 
(rag-flla rag-fila liti-nt i-rag aar ao-atora 

raaat) 

(a44r-oat rag-flla i-rag mt raaat) 

(c-f lag c-flag l-rag k-rag i-rag aar) 

(a-flag *-f lag a-tag k-rag c-flag i-rag aar) 
(a-flag a-flag a-rag k-rag c-flag 1-rag aar) 

(a-f lag « -flag a-rag k-rag c-flag 1-rag Mr) 
(a-rag a-rag vlaaal-aa* rag-flla i-rag aar raaat) 
(k-rag k-rag aiaaal-aaa rag-fila i-rag aar raaat) 
(I-rag i-rag riaaal-aaa aar) 

(alaaal-aaa raal aaa r*M arita »Mr-«at 
aaaary- iaul -4og-k 1 alary 
(4tack (car aracla)) 
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(raal aaa raal -aaa raa4 arita a44r-o«t gat a- at t 
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(raaat [car aracla))) 

(tatck-4og raa4 arita (4taek (car aracla)) 
4ata-aat aMr-aat) 

[e4r aracla) 

))) 
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Procedural abstraction 


define (FAC n) - (F n 1) 
where 

(F u v) ■ (if (zero? u) 
v 

(F (dcr u) (MPY u v))) 


define (MPY n ») ■ (M n n 0) 
where 

(M w x y) - (if (zero? w) 


y 

(if (even? w) 

(M (/2 v) x (+2 y)) 

(M (/2 w) x (+ (*2 y) 




x)))) 





















Results of Workshop Survey 


Each participant at the workshop was asked to complete a detailed survey. 1 Fifty-three people returned 
the survey; this section presents the results. 

For each question asked on the survey, the specific question is reproduced and the answers to the question 
are tabulated below. If a person circled multiple answers to a question for which only one answer was 
expected, the results were weighted. For example, in response to question 2, one Formal methods developer 
circled both b and c. This was tabulated as 0.5 for b and 0.5 for c. 

Totals or averages are given where appropriate. Not every person answered every question on the survey, 
so the totals for different questions may vary. 

1. What is the nature of your organization? 

a. University b. Formal methods developer 

c. Government d. Aerospace industry 


Question 1 

a 

b 

C 

d 

e 

Industry 

0 

0 

0 

22 

6 

Government 

0 

0 

14 

0 

0 

University 

2 

0 

0 

0 

0 

FM Developers 

0 

9 

0 

0 

0 


Note: Six people did not believe that the four listed choices accurately described the nature of their 

organization. The specific answers given were: transportation, railway transportation, non-profit 
RJkD org, industry /commercial, other, and don't know. For the purpose of recording the answers, these 
6 surveys are grouped with Industry. 


2 . 


What is your primary job function? 

a. Basic research b. Applied research c. Product development 

d. Management e. Other 


Question 2 

a 

b 

c 

d 

e 

Industry 

i 

17 

5 

2 

3 

Government 

i 

5 

0 

4 

3 

University 

i 

1 

0 

0 

0 

FM Developers 

3 

1.5 

0.5 

4 

0 

Totals 

6 

24.5 

5.5 

10 

6 


3. Please rate your understanding of formal methods theory and practice: 
a. Vovice b. Somewhat familiar c. Knowledgable 

d. Considerable e. Expert 


Question 3 

a 

b 

c 

d 

e 

Industry 

8 

10 

6 

4 

0 

Government 

6 

4 

3 

0 

1 

University 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

0 

1 

8 

Totals 

14 

14 

9 

6 

10 


1 NASA Langley personnel involved in planning and conducting the workshop did not fill out a survey. 
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Note: One of the goals of the workshop was to attract people with widely varying understanding of 

formal methods. These numbers suggest that this goal was met. 


4 . 


What is the general level of awareness of fomal methods within your organization? 
a. lone b. Minimal c. Sparse 

d. Moderate •• Considerable 


Question 4 

a 

b 

c 

d 

e 

Industry 

7 

13 

4 

1 

3 

Government 

4 

8 

1 

0 

1 

University 

0 

0 

0 

2 

0 

FM Developers 

0 

0 

1 

0 

8 

Totals 

11 

21 

6 

3 

12 


5. Before attending this workshop, how would you have rated the state-of-the-art of 
formal methods in terms of its potential for immediate application? 
a. lot usable b. Meeds more time c. learly ready 

d. Ready now •• Has been ready 


Question 5 

a 

b 

c 

d 

e 

Industry 

4 

16 

4 

3 

1 

Government 

2 

5 

4 

1 

i 

University 

0 

1 

1 

0 

0 

FM Developers 

0 

0 

6 

1 

1 

Totals 

6 

22 

15 

5 

3 


Note: Three FM developers, one who answered d and two who answered c augmented their responses 

with the comment “lor some applications.” 


6. low that you’ve attended this workshop, how would you rate the state-of-the-art of 
formal methods in terms of its potential for immediate application? 
a. lot usable b. Meeds more time c. learly ready 

d. Ready now •. Has been ready 


Question 6 

a 

b 

c 

d 

e 

Industry 

i 

16 

8 

3 

0 

Government 

0 

4 

6 

2 

0 

University 

0 

0 

2 

0 

0 

FM Developers 

0 

0 

7 

1 

1 

Totals 

1 

20 

23 

6 

1 


Note 1: See note for Question 5. b . . 

Note 2' The results to this question demonstrate that the workshop did alter some people s perceptions 
of the state-of-the-art. Particularly interesting is that before the workshop, the perception of the state of 
the art by nine people was at one or the other extreme, but after the workshop, the number of people at one 
or the other extreme was reduced to two. 


224 





7. Please rat# the extent 
organization: 
a* lever 
d. Occasionally 


to which formal methods is 

b. Seldom 
e. Often 


practiced today within your 

c . Sporadically 


Question 7 

a 

b 

c 

d 

e 

Industry 

15 

9 

2 

1 

i 

Government 

9 

3 

0 

2 

0 

University 

0 

0 

0 

1 

1 

FM Developers 

1 

0 

2 

1 

5 

Totals 

25 

12 

4 

5 

7 


Note: One FM developer answered a, and added the comment “on our own systems.” 


8. When do you think 
a. 0-2 years 
d. 10-20 years 


Question 8 

a 

b 

c 

d 

e 

Industry 

5 

7 

12 

3 

i 

Government 

4 

3 

3 

2 

0 

University 

1 

0 

1 

0 

0 

FM Developers 

5 

2 

1 

0 

0 

Totals 

15 

12 

17 

5 

1 


that formal methods will be used often in your company? 
b. 2-6 years c. 6-10 years 

e. lever 


Note: An individual from industry answered c with the comment “unless required by customers 

earlier.” 


9. low difficult do you feel it is to put formal methods into practice? 
a. Extremely b. Very c. Moderately 

d. Somewhat e. lone at all 


Question 9 

a 

b 

c 

d 

e 

Industry 

7 

9 

12 

0 

0 

Government 

2 

7 

4 

1 

0 

University 

0 

1 

1 

0 

0 

FM Developers 

2 

3 

4 

0 

0 

Totals 

11 

20 

21 

1 

0 


10. Are you personally inclined to apply formal methods on a design project in the near 
future? 

a. Strongly inclined b. Moderately inclined c. Indifferent 

d. lot inclined e. Vould quit first 
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Question 10 

a 

b 

c 

d 

e 

Industry 

13 

9 

1 

5 

0 

Government 

8 

6 

0 

0 

0 

University 

2 

0 

0 

0 

0 

FM Developers 

6 

3 

0 

0 

0 

Totals 

29 

18 

1 

5 

0 


11. How well prepared are the professionals in your organization through education and 
previous training to absorb tha technology ol loraal methods? 
a. Minimally b. Somawhat c. Adequately 

d. Receptive •• Vail praparad 


Question 11 

a 

b 

c 

d 

e 

Industry 

15 

8 

3 

0 

2 

Government 

7 

7 

0 

0 

0 

University 

0 

1 

1 

0 

0 

FM Developers 

1 

0 

0 

1 

7 

Totals 

23 

16 

4 

1 

9 


12. In your organization, which of tha following obstaclas exist 
pravant tha usa of formal mathods? (chack all that apply) 

Kanagamant baliavas it is impractical 

Engineering staff baliavas it is impractical 

Lack of sufficiant knowladga about formal mathods 
Lack of raquirad skills 

Up-front cost too high 

Hava had negative axpariancas in tha past 
Do not baliava it is useful 
Vo obstaclas axist 


Question 12 

Mgmt 

Eng 

Know 

Skill 

Cost 

Neg 

Not None 

Industry 

10 

13 

24 

20 

10 

4 

6 

2 

Government 

5 

4 

13 

11 

6 

1 

4 

0 

University 

0 

0 

1 

0 

0 

2 

0 

0 

FM Developers 

1 

2 

1 

1 

3 

0 

0 

4 

Totals 

16 

19 

39 

32 

19 

7 

10 

6 


Note: An industry representative checked Vo obstaclas axist, but added the comment except 

funding.” 


that inhibit or 

(Mgmt) 

(Eng) 

(Know) 

(Skill) 

(Cost) 

(Neg) 

(Not) 

(None) 


13. How would you rata tha potential benefits of using formal mathods? 

a. legligible b. Somewhat useful c. Moderately useful 

d. Helpful •. Significant 
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Question 13 

a 

b 

C 

d 

e 

Industry 

0 

5 

l 

4 

18 

Government 

0 

0 

l 

4 

9 

University 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

l 

3 

5 

Totals 

0 

5 

3 

12 

33 


Note: A person from industry circled e, but added the caveat, “if it does all that is advertised.” 


14. How would you rate the costs of formal methods technology relative to the costs of 
current practice? 

a. Excessively higher b. Somewhat higher c. Equivalent 

d. Somewhat lower e. Much lower 


Question 14 

a 

b 

C 

d 

e 

Industry 

4 

13 

5 

4 

2 

Government 

2 

8 

0 

0.5 

1.5 

University 

0 

2 

0 

0 

0 

FM Developers 

0 

2 

5 

0 

0 

Totals 

6 

25 

10 

4.5 

3.5 


Note I: A government representative circled e and added “over system life cycle.” 

Note 2: An industry person circled a, with the additional comment “don’t see FM replacing anything 
it only adds confidence and cost to date.” 


15. How aggressively would you recommend your management pursue the use of formal 
methods technology? 

a. Forget it 

b. Keep up with developments 

c. Attempt small pilot projects 

d. Attempt larger applications 

e. Full speed ahead 


Question 15 

a 

b 

c 

d 

e 

Industry 

0 

6 

20 

2 

0 

Government 

0 

0.5 

10.5 

2 

1 

University 

0 

0 

2 

0 

0 

FM Developers 

0 

0.5 

2 

4.5 

1 

Totals 

0 

7 

34.5 

8.5 

2 


Note: One industry representative answered c and added the comment “to completion!” 


16. How much empirical evidence on the benefits of formal methods do you feel is 
available for managers to make informed decisions regarding its use? 
a. Insufficient b. I early sufficient c. Adequate 

d. More than adequate e. Plentiful 
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Question 16 

a 

b 

c 

d 

e 

Industry 

22 

2 

3 

0 

1 

Government 

8 

2 

3 

0 

0 

University 

1 

0 

1 

0 

0 

FM Developers 

4 

3 

0 

0 

2 

Totals 

35 

7 

7 

0 

3 


R a t % tht iiportftnc# of reusable formal verifications such as verified clock 
synchronization circuits and verified software nodules, 
a. lone at all b. Somewhat c. Moderately 

d. Very •• Extremely 


Question 17 

a 

b 

c 

d 

e 

Industry 

2 

2 

7 

6 

10 

Government 

0 

5 

4 

3 

0 

University 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

0 

4 

4 

Totals 

2 

7 

11 

14 

15 


18. Rate the importance of generic tools (such as, semi-automatic theorem provers, 
specification language typecheckers) that can be applied to softwar e/hardware 

development. * . • - - . .• 

a. lone at all b. Somewhat c. Moderately 

d. Very e. Extremely 


Question 18 

a 

b 

C 

d 

e 

Industry 

0 

2 

5 

11 

10 

Government 

0 

1 

4 

6 

3 

University 

0 

0 

0 

0 

2 

FM Developers 

0 

0 

2 

2 

5 

Totals 

0 

3 

11 

19 

20 


19. Rate the importance of the capability of formal methods to produce trustworthy 
solutions of difficult problems in computer science, 
a. lone at all b. Somewhat c. Moderately 

d. Very e. Extremely 


Question 19 

a 

b 

c 

d 

e 

Industry 

i 

3 

5 

12 

7 

Government 

0 

1 

4 

4 

5 

University 

0 

1 

0 

1 

0 

FM Developers 

0 

0 

1 

2 

6 

Totals 

1 

5 

10 

19 

18 
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Note: An industry person wrote: “(a) who carat (practically) about CS? (c) for real problem*. 
Ve need trustworthy solutions to real problems!” 


20. Vhere in the life-cycle do you feel formal methods can be applied most cost- 
effectively? 

a. Requirements b. High-level design c. Detailed design 

d. Implementation e. Maintenance 


Question 20 

a 

b 

c 

d 

e 

Industry 

15.5 

8 

3.5 

0.5 

0.5 

Government 

9.33 

2.83 

1.33 

0.5 

0 

University 

0.45 

0.45 

0.45 

0.45 

0.20 

FM Developers 

1.67 

5.67 

0.33 

0 

0.33 

Totals 

26.95 

16.95 

5.61 

1.45 

1.03 


21. Vhere in the life-cycle do you feel formal methods can yield the most significant 
benefits, irrespective of cost? 

a. Requirements b. High-level design c. Detailed design 

d. Implementation e. Maintenance 


Question 21 

a 

b 

c 

d 

e 

Industry 

20.33 

2.83 

3.33 

0 

0.5 

Government 

9.33 

1.83 

0.83 

0 

0 

University 

1.33 

0.33 

0.33 

0 

0 

FM Developers 

1.5 

1.5 

3 

l 

1 

Totals 

32.5 

6.5 

4.5 

1 

1.5 


22 . 


Hov long does it take 
a. Less than 2 weeks 
d. 6 months to 1 year 


to become proficient in formal methods? 

b. 2 weeks to 1 month c. 1 to 6 months 
e. 1 to 5 years 


Question 22 

a 

b 

c 

d 

e 

Industry 

0 

0 

2 

16 

9 

Government 

0 

0 

1 

5 

6 

University 

0 

0 

0 

0 

2 

FM Developers 

0 

0 

1 

7 

0 

Totals 

0 

0 

4 

28 

17 


Note 1: Two people, one from government and one from industry, said that the answer to this question 
was “dependent on background.” 

Note S: A person from a university circled e, and annotated the answer with “or more ” 


23. Vhat is your opinion of the following statement: * 'Proficiency in formal methods 
requires a high degree of mathematical sophistication. * * ? 
a. Agree strongly b. Agree c. Vo opinion 

d. Disagree e. Disagree strongly 
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Question 23 

a 

b 

c 

d 

e 

Industry 

9 

14 

1 

2 

2 

Government 

5 

6 

1 

i 

0 

University 

0 

1 

0 

i 

0 

FM Developers 

0 

6 

0 

2 

0 

Totals 

14 

27 

2 

6 

2 


Note: An industry representative circled a, but added, “but it ahouldn ’ t ba the casa! 


24 To aach of tha following araas assign a number from 1 to B to denote the importance 
of tha area. Use i to denote that tha area is extremely important, and 5 to denote 
that the area is not important at all. Please assign a 0 to any area about which 

you hava no opinion. 

Basic modeling tachniquas 

Code verification (especially for Ada) 

Education and training 
Integrated verification systems 
Mechanical theorem provers 

Reusable deductive theories (libraries of definitions and theories) 

Reusable, verified software libraries 

Spacial purposa varification tools (such as Spactool, DDD, ft Panalopa) 

Specification languages 
Worked examples 


Question 24: Industry 
0 1 

2 

3 

4 

5 

Avg. 

Model. Tech, 

3 

11 

8 

4 

2 

0 

1.9 

Code Verif. 

4 

10 

5 

6 

3 

0 

2.1 

Education 

2 

15 

10 

0 

0 

1 

1.5 

Int. Ver. Sys, 

4 

10 

6 

5 

3 

0 

2.0 

Mech. T. Prov. 

4 

2 

11 

7 

4 

0 

2.5 

R. Ded. Theo. 

5 

5 

11 

3 

4 

0 

2.3 

R. Soft. Lib. 

2 

7 

11 

3 

5 

0 

2.2 

Sp. Purp. Tool 

5 

0 

7 

14 

2 

0 

2.8 

Spec. Langs. 

1 

14 

8 

3 

1 

1 

1.8 

Examples 

2 

11 

9 

4 

2 

0 

1.9 


Question 24: 

Government 

0 12 3 

4 

5 

Avg. 

Model. Tech. 

2 

5 

4 

0 

0 

2 

2.1 

Code Verif. 

2 

4 

2 

5 

0 

i 

2.3 

Education 

0 

6 

0 

5 

0 

2 

2.4 

Int. Ver. Sys. 

3 

0 

2 

4 

2 

1 

3.2 

Mech. T. Prov. 

1 

3 

2 

3 

1 

2 

2.7 

R. Ded. Theo. 

2 

1 

2 

4 

3 

1 

3.1 

R. Soft. Lib. 

1 

2 

2 

4 

3 

1 

2.9 

Sp. Purp. Tool 

4 

1 

2 

4 

1 

1 

2.9 

Spec. Langs. 

1 

4 

3 

2 

1 

2 

2.5 

Examples 

1 

6 

2 

2 

0 

2 

2.2 
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Question 24: University 
0 1 2 

3 

4 

5 

Avg. 

Model. Tech. 

i 

1 

0 

0 

0 

0 

1.0 

Code Verif. 

0 

0 

0 

0 

0 

0 

— 

Education 

0 

0 

0 

0 

0 

0 


Int. Ver. Sys. 

0 

0 

0 

0 

0 

0 

— 

Mech. T. Prov. 

0 

0 

0 

0 

0 

0 

- 

R. Ded. Theo. 

0 

0 

0 

0 

0 

0 

— 

R. Soft. Lib. 

0 

0 

0 

0 

0 

0 

— 

Sp. Purp. Tool 

0 

0 

0 

0 

0 

0 

— 

Spec. Langs. 

0 

0 

0 

0 

0 

0 

■— 

Examples 

0 

0 

0 

0 

0 

0 

I 


Question 24: FM Developers 
0 12 3 4 

5 

Avg. 

Model. Tech. 

0 

6 

2 

1 

0 

0 

1.4 

Code Verif. 

0 

3 

2 

2 

1 

1 

2.4 

Education 

0 

6 

2 

1 

0 

0 

1.4 

Int. Ver. Sys. 

0 

5 

1 

2 

1 

0 

1.9 

Mech. T. Prov. 

0 

3 

3 

2 

1 

0 

2.1 

R. Ded. Theo. 

0 

3 

6 

0 

0 

0 

1.7 

R. Soft. Lib. 

0 

4 

2 

4 

0 

0 

2.0 

Sp. Purp. Tool 

0 

3 

2 

1 

3 

0 

2.4 

Spec. Langs. 

0 

3 

6 

0 

0 

0 

1.7 

Examples 

0 

5 

2 

1 

1 

0 

1.8 


Note 1: Answers of 0 were ignored in calculating the averages. . , 

Note 2 ' For a few respondents, the answers to this question seemed inconsistent with answers to other 
questions. We suspect that some people may have failed to read the question carefully, and as a result reversed 
the ordering (that is, used 5 to denote extreme importance and 1 to denote no importance), however, we 
recorded their responses as given. 


25. To each of the following tools and techniques assign a number from 1 to 
5 to denote your perception of the usefulness of the tool/technique. Use 
1 to denote that you believe the tool/technique may be extremely useful, 
and 5 to denote that you believe the tool/technique is useless. Please 
assign a 0 to any tool/technique about which you have no opinion. 


Boyer- Moore 

HOL 

Penelope 

Spectool 


DDD 

Modelisation 
PVS/Ehda 


EVES 

luprl 

Safety analysis 
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Question 25: Industry 


Boyer-Moore 

HOL 

Penelope 

Spectool 

DDD 

Moderation 

PVS/Ehdm 

EVES 

Nuprl 


0 1 2 3 4 5 I Avg. 

4 10 3 1 2.9 

8 1 7 6 5 1 2.9 

12 0 9 4 3 0 2.6 

16 0 6 4 2 0 2.7 

19 0 2 4 3 0 3.1 

14 5 2 3 2 2 2.6 

5 6 10 5 1 1 2.2 

20 0 3 3 1 1 3.0 

23 0 3 0 1 1 3.0 


Safety Analysis 8 14 3 2 1 0 | 1.5 


Question 25: Government 
0 1 2 

3 

4 

5 

Avg. 

Boyer-Moore 

7 

1 

3 

2 

0 

0 

2.2 

HOL 

8 

2 

0 

3 

0 

0 

2.2 

Penelope 

11 

1 

1 

0 

0 

0 

1.5 

Spectool 

13 

0 

0 

0 

0 

0 

— 

DDD 

12 

0 

1 

0 

0 

0 

2.0 

Modelisation 

8 

1 

2 

0 

0 

0 

1.7 

PVS/Ehdm 

7 

3 

1 

2 

0 

0 

1.8 

EVES 

12 

0 

0 

1 

0 

0 

3.0 

Nuprl 

12 

0 

0 

1 

0 

0 

3.0 

Safety Analysis 

5 

5 

1 

1 

0 

1 

1.9 | 


Question 25: University 

0 1 2 3 4 5 | Avg. 


Boyer-Moore 01 1000 1.7 

HOL 0 0 2 0 0 0 2.0 

Penelope 1 0 1 0 0 0 2.0 

Spectool 1 0 1 0 0 0 2.0 

DDD 1 0 1 0 0 0 2.0 

Modelisation 2 0 0 0 0 0 

PVS/Ehdm 0 2 0 0 0 0 1.0 

EVES 0 0 1 1 0 0 2.5 

Nuprl 0 0 2 0 0 0 2.0 

Safety Analysis 1 0 0 0 1 0 4.0 


Question 25: FM Developers 

0 1 2 3 4 5 1 Avg. 


Boyer-Moore 0 0 5 1 0 0 2.2 

HOL 0 0 3 2 2 0 2.9 

Penelope 0 3 0 2 2 0 

Spectool 1 3 0 3 0 0 

DDD 201301 

Modelisation 3 11110 

PVS/Ehdm 0 15 10 0 

EVES 113200 

Nuprl 0 0 0 1 4 2 4. 

Safety Analysis 2 12 110 2. 


0 3 0 2 2 0 

1 3 0 3 0 0 2.0 

2 0 1 3 0 1 

3 11110 

0 1 5 1 0 0 2.0 

1 1 3 2 0 0 

0 0 0 1 4 2 4.1 











Note: See the notes for Question 24. 


26. How expressive should a formal language be? 

a. Very expressive (such as Z and VDM) b. To the level of higher-order logic 

c. To the level of 1st order logic d. To the level of Prolog 

e. To the level of propositional calculus 


Question 26 

a 

b 

c 

d 

e 

Industry 

14 

6 

2 

1 

0 

Government 

2 

4 

0 

0 

1 

University 

1 

0.5 

0.5 

0 

0 

FM Developers 

3 

4 

2 

0 

0 

Totals 

20 

14.5 

4.5 

1 

1 


Note: Four people, one from industry and three from government, did not answer this question, but 

wrote the following comments instead: “depends on application,” “to understanding of user,” “this 
needs to be decided on the basis of the domain of application requirements ” and “depends on 
when it is used.” 


27. How important is it to have a specification language that can mimic the notation 
typically employed in the problem domain? 

a. lone at all b. Somewhat c. Moderately 

d. Very e. Extremely 


Question 27 

a 

b 

c 

d 

e 

Industry 

0 

3 

5 

12 

6 

Government 

0 

2 

3 

2 

5 

University 

0 

0 

0 

1 

1 

FM Developers 

0 

0 

3 

4 

2 

Totals 

0 

5 

11 

19 

14 


Note 1: A member of the government answered e, and included the comment: “to be accepted by 

the engineers and program managers ” 

Note 2: Another government representative did not circle an answer, but wrote “It must not necessarily 
mimic but must be readable by experts in the problem domain.” 


28. How important is the availability of powerful decision procedures in a theorem 
prover (for example, decision procedures for linear arithmetic and propositional 
calculus)? 

a. lone at all b. Somewhat c. Moderately 

d. Very e. Extremely 


Question 28 

a 

b 

c 

d 

e 

Industry 

0 

3 

8 

7 

5 

Government 

0 

1 

3 

3 

2 

University 

0 

0 

1 

1 

0 

FM Developers 

0 

0 

1 

2 

6 

Totals 

0 

4 

13 

13 

13 
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29. To #ach o 1 the following areas assign a number from 1 to 6 to denote your opinion 

as to the importance of NASA sponsoring work in the area. Use 1 to denote that you 
believe it is extremely important for NASA to sponsor work in the area, and 6 to 
denote that you believe NASA should not sponsor any work in the area. 

Theoretical research (for example, developing theorem provers) 

Applied research (for example, pilot projects applying formal methods) 
joint projects between traditional engineering groups and formal methods experts 
Workshops such as this one 


Question 29: Industry 
0 

1 

2 

3 

4 

5 

Avg. 

Theore tical Research 

0 

8 

5 

7 

3 

r> 

2.7 

Applied Research 

0 

19 

(5 

0 

0 

3 

1.6 

Joint Projects 

0 

23 

2 

2 

1 

0 

1.3 

Workshops 

0 

17 

7 

2 

2 

0 

1.6 


Question 29: Government 
0 1 

2 

3 

4 

5 

Avg. 

Theoretical Research 

0 

3 

5 

I 

4 

6 

2.5 

Applied Research 

0 

10 

1 

J 

0 

i 

1.5 

Joint Projects 

0 

9 

3 

0 

1 

0 

1.5 

Workshops 

0 

11 

1 

0 

0 

i 

1.4 


Question 29: University 
0 1 

2 3 

4 

5 

Avg. 

Theoretical Research 

0 0 

1 1 

0 

0 

2.5 

Applied Research 

0 2 

0 o 

0 

0 

1.0 

Joint Projects 

0 1 

1 0 

0 

0 

1.5 

Workshops 

0 1 

1 0 

0 

0 

1.5 


Question 29: FM Devt 

0 

dopers 
1 2 

3 

4 

5 

Avg. 

Theoretical Research 

0 

4 

2 

2 

1 

0 

2.0 

Applied Research 

0 

5 

4 

0 

0 

0 

1.4 

Joint Projects 

0 

5 

4 

0 

0 

0 

1.4 

Workshops 

0 

2 

4 

2 

1 

0 

2.2 


Note: See the notes for Question 24. . . ._ J _ 

Questions 30-32 were not multiple choice. Only a few representative comments from each organizational 
category are included below. These comments are presented exactly as given; no editing has been done. For 
these questions, Government and University participants have been grouped together. 


30. What formal methods have you used? 

Industry: Boycr-Moore, cleanroom, Clio, BIIDM, 1I01-, Spec tool, temporal logic, VDM, Z 

Gov & Univ: Boyer-Moore, cleanroom, DDD, KIIDM, IIOL, VDM 
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FM Developers: Boyer-Moore, Clio, EHDM, EVES, HOL, PVS, Penelope, SDVS, Spectool, temporal 
logic , Z 


31. In what application* and parts of the life-cycle have you used formal methods? 

Industry: requirements modeling, design, and testing, conceptual study, detailed design, verification of 

algorithms, implementation 

Gov & Univ: software requirements, high level requirements, avionics software, missile systems, electronic 

message systems, design, implementation, academic research projects 

FM Developers: hardware designs, microcode, detailed design, algorithms, high-level HW design 


32. Any additional comments? 

Industry: 

e * 'Workshops of this type where interested industries can attend and participate are 
excellent opportunities for technology transfer. I would encourage IASA to continue 
this type of interaction. ’ ’ 

• "I would very much like to see a survey of (1) methods (2) languages k (3) tools 
presenting PROs k COVs of each. As a novice wanting to enter the field, where do 
I start? ’ * 

• " Tools are very important to this effort. Paper and pencil will not spread to industry.* ’ 

• “It would have been nice to actually solve some simple problems using a formal technique 
rather than seeing lots of talks about proof a.” 

• ' ‘Suitable applications of FNs was not elaborated on. I still cannot say ( where y 
one should apply 'what’ FM. " 

• ,f Veed to separate HW FM’s from SW FM’s." 

• ‘‘This is one of the only forums I have attended that has had equal representation 
from the software and hardware community sharing roughly equal concerns and a common 
interest in a technology of equal value and benefit to eaclx community.’’ 

• "You are overcautious about overselling. , 

Gov & Univ: 

• 1 'We must find a way to better find errors in Reqm’ts" 

• "It is important for IASA to take a leadership position in Formal Methods for civilian 
aerospace applications. ’ ’ 

e 1 'FM appears to be currently the most feasible means of adding rigor and consistency 
to the software development process.’’ 

• ''Keep holding this workshop!’’ 

• "I really wish copies of slides had been available at the conference. It would greatly 
simplify notetaking. ’ ’ 

FM Developers: 

• "There is no 'royal road’ to FM for industry." 

• 1 'FM is powerful for educating designers." 

• "Formal methods are no panacea" 
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NASA Formal Methods Workshop Attendees 


Jorgen B. Andersen 
Honeywell, Inc. 

Box 211 11 

Phoenix. AZ 85036-1111 
Bob Baker 

Research Triangle Institute 
POBox 12194 

Research Triangle Park, NC 27709-2194 
rlb@rti.rtl.org 

Mark Bickford 

Odyssey Research Associates, Inc. 

301 Dates Drive 
Ithaca, NY 14850 
email: mark@oracorp.com 

Bhaskar Bose 
Indiana University 
215 Lindley Hall 
Bloomington, IN 47405 

Daniele Bozzolo 

Union Switch and Signal, Inc. 

5800 Corporate Drive 
Pittsburgh, PA 15237 


Jerome F. Coffel 
Honeywell, Inc. 

3660 Technology Drive 
MN65-3240 

Minneapolis, MN 55418 
email: jcoffel@src.honeywell.com 

Richard Covington 

NASA Jet Propulsion Laboratory 

MS 125-233 

4800 Oak Grove Drive 

Pasadena, CA 91109 

Dan Craigen 
ORA Canada 
265 Carling Avenue 
Suite 506 

Ottawa, Ontario KIS 2E1 
CANADA 

email: dan@ora.on.ca 

Ronald T. Crocker 
Motorola, Inc. 

1501 West Shure Drive 
Arlington Heights, IL 60004 
email: crocker@mot.com 


Ricky W. Butler 

NASA Langley Research Ctr. 

Mail Stop 130 

Hampton, VA 23681-0001 

email: rwb@airl6.larc.nasa.gov 


Mark Crosland 
Boeing 
MS 88-12 
P.O. Box 3707 
Seattle. WA 98124 


Jim Caldwell 

NASA Langley Research Center 
Mail Stop 130 
Hampton, VA 23681-0001 
email: caldwell@cs.comell.edu 


Jim Dabney 
Intermetrics, Inc. 
1100 Hercules 
Suite 300 

Houston, TX 77058 


Victor Carreno 

NASA Langley Research Center 
Mail Stop 130 
Hampton. VA 23681-0001 
email: vac@airl6.larc.nasa.gov 


Mike DeWalt 
FAA 

ANM-106N 

1601 Lind Avenue, S.W. 
Renton, WA 98055-4056 
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Ben Di Vito 
Vigyan, Inc 

NASA Langley Research Center 
Mail Stop 130 
Hampton, VA 23681-0001 
email: bld@airl6.larc.nasa.gov 

Audrey Dorfman 
Vitro Corporation 
600 Maryland Ave., SW 
Suite 300, West Wing 
Washington, DC 20024 

George Finelli 

NASA Langley Research Center 
Mail Stop 130 
Hampton, VA 23681-0001 
email: gbf@airl6.larc.nasa.gov 

Gene Fisher 

California Polytechnic State Univ. 
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